A per-user token quota rests on three decisions: who the user is, what you count, and who answers when the limit is reached. The first one decides whether the other two mean anything. If the browser or the mobile app can set the user id or the plan name, a caller can change whose quota is charged, and the quota holds only for users who don't try.

Two claims run through this article. First, the gateway counts, but your backend decides who is counted. Authentication and the entitlement lookup belong on your side of the trust boundary, and whatever the gateway receives is an assertion from whoever holds the API key. Second, a 429 tells you that someone refused, not who refused or why. A provider rate limit, a per-user quota and your gateway vendor's own plan limit can all arrive as 429, and each needs a different response from your client.

Everything below that describes expected behavior is a design criterion, not a result from tests we ran. The user ids, plans and limits are fictional.

The gateway counts.…