Authentication

Every call your backend makes to an Invokation API is authenticated with credentials issued to your game. Credentials are created, rotated, and revoked in the portal.

Calls come from your backend, never your client

The API is a backend-to-backend surface. Your game client talks to your backend; your backend talks to us.

Secrets are only part of the reason. Your backend is where authentication, anti-cheat, skill lookup, and rate limiting already live, and it is the boundary that lets you change matchmaking behaviour without shipping a client build. A credential embedded in a game client can be extracted from it, and whoever extracts it can act on your queues.

Keep credentials in the same secret store as the rest of your backend’s secrets, and load them the same way. They do not belong in queue configuration, in source control, or in a game client.

Attaching credentials

Credentials are bearer tokens, carried in an Authorization header on every request. Both transports work the same way, and both require TLS.

Authorization: Bearer <token>

Over gRPC that is call metadata; over HTTP/JSON it is an ordinary request header. The header name and format are identical either way.

Issue a token in the portal and it is shown once. Store it then; it cannot be retrieved again, only replaced.

Endpoints

Service	Endpoint
IVK Match	`match.ivk.dev`

TLS is terminated at the endpoint, so use https:// for HTTP/JSON and a TLS channel for gRPC. Plaintext connections are rejected.

Rotation

Credentials can be rotated without downtime: issue the new one, deploy it, then revoke the old one. Because a credential authenticates a game rather than a single queue, rotating it affects every queue on that game at once, so make the overlap window long enough to cover a full deploy.

Losing a credential

Revoke it in the portal. Revocation takes effect immediately and any backend still presenting the old credential starts failing authentication, so deploy the replacement first where you can.