Authentication
Bearer keys for the Feed Builder API, where to get one, and what each refusal means.
Every route under /v1 is authenticated with a Feed Builder 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 → Builder API Keys. A key looks like:
sk_fb_live_4f2b9c1d7a3e0518_9c8d… (public half)_(secret half)The key is shown once and we cannot recover it
We store the public half in the clear and a one-way hash of the secret half. The secret itself never reaches our database, so nobody at String can read your key back to you — not support, not an engineer with database access. If you lose it, revoke it and generate a new one. Put it in your secret manager, never in source control.
The public half is what the portal lists, and it is safe to quote in a support request or a log line. The whole key is not.
Feed Builder 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. There is no way to act as another, and there is no request field that lets you
try: a body carrying org_id, organization_id, user_id, submitted_by or any casing variant of them is refused
with a 400 at any nesting depth, rather than silently overwritten.
That refusal exists because the alternative is worse than an error. A caller who believes their org_id took effect
ships an integration that looks multi-tenant and is not.
The one exception is questionnaire.answers, whose object keys are the builder's own question ids rather than field
names — see Gates.
Because a key identifies an organization and not a person, gate answers and messages are recorded without an author.
What each refusal means
| Status | Meaning |
|---|---|
401 | The key is missing, malformed, unknown, or its secret does not match. All four give the same code and message. |
503 | Our key store is unreachable. Your key is fine — retry. |
The 401 is deliberately uninformative: four different failures collapse into one answer so that the key format
cannot be probed one refusal at a time. Do not branch on the message.
The 503 matters just as much in the other direction. If an unreachable key store answered 401, you would rotate a
perfectly good key in the middle of our incident and page us about it. A 503 here is always ours, and always
retriable.
Revoking a key
Revoke in the portal. Revocation takes effect at the API within the key cache's TTL rather than instantly — see Limits. If a key has leaked, revoke it and treat the TTL as the exposure window.