API sends both Authorization Bearer and x-api-key: 401
Sume rejects a request that carries both Authorization: Bearer and x-api-key with 401 and 'Send only one API key credential.' Neither header wins. Fix it.
Sume answers 401 unauthorized with the message Send only one API key credential. when a request carries both Authorization: Bearer and x-api-key. There is no precedence rule: neither header wins, and the second does not silently shadow the first. Strip one of them and the same key works.
Which combinations does the API accept?
The docs say to use one form consistently in each integration.
| Headers sent | Result |
|---|---|
x-api-key only | Accepted |
Authorization: Bearer only | Accepted |
| Both | 401 unauthorized, Send only one API key credential. |
Where does the second header come from?
The docs name the usual culprit: gateways and fetch wrappers that add an Authorization header of their own on top of a client that already sends x-api-key. The @sume-com/sdk client sends x-api-key only and does not set Authorization, so an Authorization header you add, such as a session token, a gateway credential or a forgotten interceptor, fails the request even though the key was correct. If you wrap fetch through the client's fetch option, check that the wrapper is not adding one.
How do I check which one is being sent?
Send the smallest possible request with a single header and confirm it succeeds, then compare with what your stack actually sends.
curl https://api.sume.com/v1/me \
-H "x-api-key: $SUME_API_KEY"Should I keep Bearer or x-api-key?
Either. The Sume CLI defaults to x-api-key and can use Bearer mode when configured. Pick the one your proxy will not duplicate, and remove the other rather than relying on a precedence rule that does not exist.
What does a correct server-side proxy send?
Browser and mobile clients should call your backend, and your backend should attach the Sume API key. The docs example forwards with a single Authorization: Bearer header built from SUME_API_KEY, plus Content-Type and an Idempotency-Key. If your proxy also copies the caller's incoming headers, make sure it does not pass through a second credential.
Is every 401 this problem?
No. A 401 is also what a missing, malformed or revoked key returns, and the docs say to check the header and create a new key if needed. The message text tells them apart: the both-headers case says Send only one API key credential.
What about MCP clients and other wrappers?
The same rule is about the credential on the request, not about the client. Any tool that adds its own Authorization header on top of a configured x-api-key, or the other way round, sends two credentials. Check the final request your stack emits, not only the value you configured, and keep one credential per integration.
Sources
Related posts
More in Developers
- Sume webhook retry schedule: 10 attempts, then what?
Sume tries a webhook up to 10 times. Job webhooks use a fixed 30 s gap; run webhooks back off with jitter up to an hour. What happens next, and how to replay.
- Suno alternative with an API: what Sume's Music Router does
Looking for a music generator you can call from code? What Sume's Music Router takes in, returns and does not do, so you can decide if it fits.
- Suno API: the music API options and what Sume offers
Looking for a Suno API? Sume does not list Suno, but the Music Router takes a prompt and returns audio. Request shape, async polling, limits and fixed price.
- Suno old models retired, what now? Keep a music API stable
Vendors retire music models and Sume's Music 1.0 is retiring gradually too. Call the router, log job.model and routed_model, and pin ids so changes are visible.
Written by Sume