mTLS instead of an API key? How Sume authenticates calls
OpenAI's docs list mutual TLS and workload identity federation. Sume authenticates API calls with one API key header and signs webhooks with HMAC.
Sume's public API authenticates with an API key, sent either as Authorization: Bearer or x-api-key, exactly one of them. The docs do not describe mTLS or workload identity federation for calls into Sume. Webhooks coming out of Sume are a separate path, signed with HMAC SHA-256 and checked with verifyWebhook.
On the OpenAI side, this post only relies on what the page navigation shows (read 2026-10-01): its API docs list Mutual TLS, Workload identity federation, and X.509 certificates. The snapshot did not include those pages' contents, so nothing more is claimed about how they work. Sume facts are from Authentication.
What does Sume use to identify a caller?
An API key. Sume resolves the workspace, owner, and key metadata from the key, so you do not put workspace_id or user_id in request bodies. Send exactly one credential: a request carrying both Authorization: Bearer and x-api-key is rejected with 401 unauthorized, and neither header wins. Gateways that add their own Authorization header on top of a client that already sends x-api-key are the usual cause.
How are webhooks authenticated instead?
The receiver checks a signature rather than a client certificate. Sume signs the raw body with HMAC SHA-256 over {timestamp}.{raw_body} and sends x-sume-webhook-timestamp and x-sume-webhook-signature: sume-v1=....
| Direction | Proof | Where it is documented |
|---|---|---|
| Your code calls Sume | One API key header | Authentication |
| Sume calls your URL | sume-v1 HMAC signature plus timestamp | Verifying webhooks |
| Same delivery sent twice | Dedupe on job_id | Webhooks: receivers must treat job_id as the idempotency key |
Where does the signing secret come from?
It is derived for your workspace; read it in the dashboard Webhooks tab or from GET /v1/webhooks/signing-secret with a key that has account:read. It is not the API key. The dashboard shows a fingerprint, and each delivery carries x-sume-webhook-secret-fingerprint, so when verification fails you can compare fingerprints without pasting the secret; see comparing the fingerprint.
What should I check if I need certificate-based identity?
Confirm with Sume's docs and your account contact before designing around it, since the docs reviewed here describe only the key header and the webhook signature. Keep the secret out of source control and rotate it if it may have leaked; rotation signs deliveries with both secrets for 24 hours.
Sources
Related posts
More in Developers
- OpenAI v1/prompts shuts down Nov 30, 2026: saved media recipes
OpenAI plans to shut down reusable prompt objects and v1/prompts on Nov 30, 2026. For media work, a Sume Format is a saved recipe you call by name.
- OpenAI service-account-only keys, and Sume Format run limits
OpenAI admins can allow only service-account keys. On Sume, service-account keys cannot create Format runs or bulk queues; use a user-issued key.
- OpenAI speech API has six formats; Sume TTS has mp3, wav, raw
OpenAI lists MP3, Opus, AAC, FLAC, WAV and PCM for speech output. Sume TTS 1.0 has three containers: mp3, wav and raw, with set sample rates and encodings.
- OpenRouter 402 with credits left vs Sume 402 on reserve
OpenRouter can return 402 with a positive balance when the in-flight budget is full. Sume's 402 means the estimate could not be reserved. Telling them apart.
Written by Sume