How a request is authenticated
The Authorization header carries a Bearer credential shaped as a key ID and a secret joined by a dot. The key ID selects the account and the secret is checked with an HMAC comparison; a failed check answers 401 with MISSING_API_KEY or INVALID_API_KEY before the route itself runs. Nothing else is inspected β no cookie, no CSRF token, no origin header.
IP allowlisting
A key can be pinned to a set of source addresses. While that list is non-empty, a request from any other address is refused with IP_NOT_ALLOWED and HTTP 403 β ahead of rate limiting and ahead of any wallet lookup β so a stolen credential cannot be used off your own infrastructure. An empty list means the key works from anywhere.
Account state
Two account-level conditions short-circuit every endpoint: a disabled account answers ACCOUNT_DISABLED and a frozen one answers ACCOUNT_FROZEN, both with HTTP 403. Neither clears itself, so raise them to a human instead of retrying in a loop.
Key rotation
Keys are created and deleted on the API Access page of the reseller panel. The secret is shown once at creation, so rotation is create, deploy, delete rather than an in-place edit. Credentials do not expire on their own, which means the rotation schedule is yours to set.
New to the platform? Start with the game top-up API overview for resellers, or read the SHOP2TOPUP reseller programme overview for how the partner account works.