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 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.
- Punch-in zoom on video by API: crop or zoompan, no keyframes
Sume has no auto zoom switch. Use a crop op for a fixed punch-in or the allowlisted zoompan filter in a video-filter graph; there are no keyframes.
- remove.bg API rate limit: 500 per minute, weighted by megapixels
remove.bg allows 500 images per minute at about 1 MP, less for larger inputs. Sume limits requests per minute per key and sends retry-after on 429.
- remove.bg bg_color replacement: Sume RMBG gives a transparent PNG
remove.bg's API has bg_color and bg_image_url. Sume RMBG 1.0 takes only an image_url and returns a PNG with alpha, so the new background is a second step.
Written by Sume