Send a key
How your backend sends the frontend key, and what a refused key gets.
Send the key as a bearer token in the Authorization header of every call to the Members API:
POST <studio>/api/v1/members/eligibility Authorization: Bearer ofk_3f9a1c2b7d4e_… Content-Type: application/json
A call on behalf of a signed-in frontend user also carries that user's access token, in its own header beside the key, never instead of it (see The signed-in member).
A refused key
Every refusal gets the same answer, whatever the reason:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
{"error": "unauthenticated"}
That covers a missing header, another scheme than Bearer, a malformed, unknown or revoked key, and the key of a disconnected frontend. The Studio does not say which, so check the key you deploy against the prefix on the "Keys" card, and ask the organisation whether the frontend is disconnected.
Nothing is cached: a revoked key is refused from the next request on, and the key of a reconnected frontend works again at once.
When the Studio cannot answer
503 {"error": "unavailable"} means the Studio itself failed. The key is fine: retry later, and do not rotate it.