Why a key was refused
Every refused call to the API returns the same body, whatever the reason:
{
"error": {
"code": "unauthorized",
"message": "Invalid API credentials."
}
}
That is deliberate. Saying which wall a key hit would tell someone guessing at keys how close they got. But it also meant that when your own integration was refused, you had nothing to go on.
What changed
The Credentials page now has a Refused requests table. It appears only when something was refused, and lists the reason in words, which key it was, how many times it happened, and when it was last seen. You have already signed in to see it, so there is nothing left to hide from you.
| Reason | What happened |
|---|---|
live_not_approved | A production key on an application that is not approved yet. |
credential_revoked | The secret was rotated, and something is still holding the old one. |
app_suspended | This application is suspended. |
partner_suspended | The whole account is suspended. |
Why it matters
The most common case is a rotation that outran a deploy. Before this, a rotated secret looked exactly like a wrong one. It is now recorded as credential_revoked, and the count tells you how much of your fleet is still holding it.
A secret that matches no application at all is refused and recorded nowhere. Otherwise anyone could fill your table with noise.
What to do
Nothing. The next time a call comes back 401 or 403, open the application's Credentials page before you open a support ticket. Errors and status has the full list.
Breaking changes
None. Status codes and response bodies are exactly what they were.