Skip to content

authentication_error

HTTP 401. The request carried no usable credential.

401 — no key at all
{
"error": {
"type": "authentication_error",
"message": "Missing API key.",
"docs_url": "https://galleyrender.com/docs/errors/authentication_error",
"details": {
"how_to_authenticate": "Send `Authorization: Bearer glr_sk_…` or `X-API-Key: glr_sk_…`.",
"get_a_key": "https://galleyrender.com/docs/quickstart"
}
}
}
401 — a key we do not recognise
{
"error": {
"type": "authentication_error",
"message": "Invalid or revoked API key.",
"docs_url": "https://galleyrender.com/docs/errors/authentication_error",
"details": {
"header": "Authorization: Bearer glr_sk_…",
"get_a_key": "https://galleyrender.com/docs/quickstart"
}
}
}

Three raise sites:

  • Missing key — neither Authorization nor X-API-Key was present on a /v1 request. Note that X-API-Key is only consulted when Authorization is absent or empty.
  • Unknown or revoked key — the presented key’s hash matches no live key. Mistyped, truncated, from another environment, or revoked. The two cases are deliberately not distinguished.
  • Invalid internal secret — the service-to-service onboarding routes under /v1/internal/* reject a bad X-Galley-Internal-Secret. Those routes are not public API.

A common cause is shell quoting: -H "Authorization: Bearer $GALLEY_API_KEY" with an unset variable sends the literal string Bearer .

Confirm the variable is set and is the whole key, glr_sk_ prefix included. Check you are calling api.galleyrender.com and not the MCP host, which takes X-Galley-Api-Key instead. If the key was revoked, issue a new one and redeploy. Full detail: Authentication.

No. Nothing about the credential changes between attempts.