Authentication
Bearer keys for the Composer API, where to get one, and what each refusal means.
Every route under /v1 is authenticated with a Composer API key, sent as a Bearer token:
Authorization: Bearer sk_fb_live_…The scheme name is matched case-insensitively (RFC 7235), so bearer works too.
Getting a key
Generate one in the portal under Feeds → Composer API Keys. A key looks like:
sk_fb_live_4f2b9c1d7a3e0518_9c8d… (public half)_(secret half)The key is shown once and cannot be recovered
Nobody at String can read it back to you. If you lose it, revoke it and generate a new one. Keep it in your secret manager, never in source control.
The public half — everything up to the second _ — is what the portal lists, and it is safe to quote in a support
request or a log line. The whole key is not.
Composer keys are not Web Access keys
They are separate credentials against separate APIs and are not interchangeable. A Web Access key presented here is a
401, and the same is true in reverse.
The tenant comes from the key, and only from the key
A key resolves to one organization, and nothing in a request can change that. A body carrying org_id,
organization_id, user_id, submitted_by or any casing variant is refused with a 400 at any nesting depth —
refused, not silently overwritten, so an integration cannot look multi-tenant while not being one.
The one exception is questionnaire.answers, whose object keys are Composer's own question ids rather than field
names — see Gates.
What each refusal means
| Status | Code | Meaning |
|---|---|---|
401 | missing_api_key | No Authorization header at all, or a scheme other than Bearer. |
401 | invalid_api_key | A key was presented and not accepted. Malformed, unknown and wrong-secret are one answer. |
503 | — | Our key store is unreachable. Your key is fine — retry. |
Malformed, unknown and secret-mismatch are one answer, so do not branch on the message. Every 401 carries
WWW-Authenticate: Bearer realm="feedbuilder-api".
A 503 is always ours and always retriable — never rotate a key in response to one.
Revoking a key
Revoke in the portal. Revocation takes effect at the API within 60 seconds rather than instantly, because keys are cached for that long — see Limits. If a key has leaked, revoke it and treat those 60 seconds as the exposure window.