REST API
Kommer snartAPI-referanse
Den fullstendige API-referansen vil auto-genereres fra vår OpenAPI 3.1-spec i det surface er stabil. Vi shipper heller en placeholder enn å fake-doke endepunkter som fortsatt kan flytte seg. I mellomtiden, her er formen, hva den vil dekke og hva du gjør i dag.
Form (kan endres)
REST over HTTPS. JSON inn, JSON ut. Versjonert i path: /v1/.... Det finnes to autentiseringsskjemaer, og det du sender erklærer hva slags principal du er: Authorization: ApiKey <prefix>.<secret> for et programmatisk kall, Authorization: Bearer <token> for en innlogget session. Hver route bestemmer selv hvilke typer den godtar, så ingenting kan utledes av URL-en: de fleste prosjektroutes tar imot begge, /v1/mcp/* tar kun API-nøkler, og konto- og staff-routes tar kun sessionen. Alt annet gir 401. Scopene til en API-nøkkel mappes til en prosjektrolle før rettighetskontrollen (project:read blir viewer, project:write eller cdn:write blir developer). Vær oppmerksom på Bearer: på /v1/feedback/* og /v1/in-context/* bærer den et sluttbrukertoken med begrenset rekkevidde, en annen tokenfamilie enn en session; sjekk hvilken den aktuelle flaten forventer. Rate-limits gjelder bare tre flater (feedback, bundle, missing), og headerne deres har prefiks per familie: X-Feedback-RateLimit-Limit, -Remaining, -Reset, pluss X-Feedback-Quota-Remaining. Det finnes ingen generisk X-RateLimit-*-header, og alle andre /v1/-endpoints returnerer ingen begrensningsheadere i det hele tatt. Tellingen skjer per organisasjon, ikke per API-nøkkel: å utstede en nøkkel nummer to øker ikke budsjettet ditt, den deler det.
curl 1# hvert endepunkt tar en API-nøkkel i Authorization-headeren2curl https://api.sonenta.dev/v1/projects \3 -H "Authorization: ApiKey snt_live_<prefix>.<secret>" 5{ "data": [{ "id": "proj_xxx", "name": "Checkout", … }] }API-nøkler kommer fra Org Settings → API Keys i dashbordet. Samme nøkkel fungerer for CLI-en, MCP-serveren og direkte REST-kall, API-en konsumerer bare beareren.
Ressurser ved lansering
Dette er ressursene V1-API-en vil eksponere. Den eksakte formen, felter, feilkoder, paginering, lander når vi publiserer OpenAPI-specen.
| Ressurs | Hva den representerer | V1-ops |
|---|---|---|
| Projects | Workspaces. Opprett, list, arkiver, overfør ownership. | GET · POST · PATCH · DELETE |
| Locales | Prosjekt-scoped locale-sett. Legg til en locale, marker som default, aktiver/deaktiver for klienter. | GET · POST · PATCH · DELETE |
| Namespaces | Logiske bøtter av nøkler per prosjekt (f.eks. "checkout", "common"). | GET · POST · PATCH · DELETE |
| Keys | Oversettelsesnøkler med beskrivelse, screenshot-URL-er, max-length, flertallsregler. | GET · POST · PATCH · DELETE |
| Translations | Verdi per locale for en nøkkel. Draft-, in-review-, approved-states; revisjonshistorikk. | GET · POST · PATCH · DELETE |
| Missing keys | Runtime-SDK-ens kø. List, grupper etter frekvens, marker som triagert. | GET · PATCH |
| Webhooks | Abonner på oversettelsesevents. V2. | V2 |
Hva du gjør i dag
Nesten alt du ville brukt API-en til er allerede eksponert via CLI-en, MCP-serveren eller runtime-SDK-en. Bruk dem, når API-en lander, kan koden din bytte til direkte HTTP-kall uten å endre hva den faktisk gjør.
Når lander den offentlige referansen?
Den offentlige OpenAPI-specen vil serveres på https://api.sonenta.dev/openapi.json så snart V1-surface er frosset. Derfra bytter denne siden fra placeholder til en fullt rendret referanse (Stoplight eller lignende viewer over specen), ingen markedsføringstekst, bare hvert endepunkt, hver payload, hver feilkode, generert fra kilden.