HTTP API

Prefer the typed build integration and matching framework runtime. Direct HTTP integration is useful for diagnostics and nonstandard build systems but must preserve the same schemas and safety rules.

Build endpoints

Method and path	Purpose
`POST /api/v1/manifests`	Register manifest metadata and receive optional presigned upload
`POST /api/v1/manifests/:id/complete`	Confirm artifact upload and validation
`POST /api/v1/manifests/:id/translations`	Request bounded target-locale jobs
`GET /api/v1/jobs/:id`	Read job, dispatch, error, and catalog state
`POST /api/v1/manifests/:id/development-release`	Publish successful build catalogs to development

Send Authorization: Bearer <project token> and a deterministic Idempotency-Key. Manifest registration uses the manifest content hash. Never send project authorization to a presigned object-storage URL; use only the returned upload headers.

Runtime endpoint

GET /api/v1/catalogs/:project/:environment/:locale uses x-linguana-key: <publishable key>. Verify the returned catalog schema, integrity, and scope before rendering.

Dashboard strings endpoints

The Strings API lists source text, reads version history, saves human edits with optional expectedVersion, and reviews selections. These routes use dashboard sessions and organization roles, rather than project tokens or publishable keys. Acceptance and catalog readiness are separate from publication.

Runtime configuration is available at GET /api/v1/runtime/projects/:project/environment/:environment, also using x-linguana-key. Use the environment name that matches your published catalog.

Errors

SDK-consumed JSON failures may contain code, message, and requestId. Preserve code and request ID in redacted telemetry. HTTP status alone is insufficient to distinguish cap, provider, dispatch, validation, or scope failures.

Idempotency

Retry the same logical request with the same key. Inventing a new key after a timeout can create parallel work and duplicate reservations.