503 api_key_auth_unavailable on Sume: your key is fine

A 503 api_key_auth_unavailable or api_key_auth_not_configured is Sume's auth check failing, not a bad key. Keep the key, back off, and read request_id.

4 min readSume
All posts

Most auth failures on the Sume API are 401, and they mean the key is missing or wrong. A 503 on an authenticated call is a different thing. If the response carries the code api_key_auth_unavailable, with the message "API key authentication is temporarily unavailable," the key was never judged. Sume could not look it up.

Two codes, one meaning

The auth step has two 503 branches. If the server has no secret for hashing API keys, the code is api_key_auth_not_configured and the message is "API key authentication is not configured." For any other failure while authenticating, such as an outage in the key store, the code is api_key_auth_unavailable.

In the documented example for the unavailable code, retryable is false, retry_after_seconds is null, and next_action is contact_support. That is conservative guidance for an unknown outage. In a client, you can still make a couple of spaced retries, because the same request will pass when the store is back. But do not loop for minutes.

What not to do

Do not revoke or rotate the key. Rotation will not fix a lookup outage, and it breaks every other service that holds the old key. Do not send the request with both Authorization and x-api-key to see which one works, because that gets a 401 saying to send only one credential.

Check the shape of the failure first. A 401 means credentials; a 503 with these codes means the platform. Look at the error envelope fields, including category runtime_unavailable and stage runtime in the docs example, and keep the request_id.

curl -sS -i https://api.sume.com/v1/jobs/job_does_not_matter/status \
  -H "Authorization: Bearer $SUME_API_KEY" | head -n 20

Alerting

Route these two codes to the platform channel, not to key owners. A 401 spike usually points at keys. A 503 spike with these codes means wait and, if it lasts, send the request ids to support. If jobs were already created before the outage, they continue; read them again when auth returns, and never resubmit a paid create without its original Idempotency-Key.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume