Authentication
Server-to-server calls authenticate with a bearer API key, scoped to a workspace and a permission set.
Bearer keys
curl -H "Authorization: Bearer pg_live_…" \
https://hub.playgent.com/api/v2/games
Use the Authorization: Bearer <api_key> header. Keys begin with pg_live_ followed by ~50 base64url characters.
Where keys come from
Hub → Developers → API keys → New API key. Pick a name that explains where this key will be used (e.g. Production worker).
The full key is shown only once. Copy and store it in your secret manager — Playgent stores only a SHA-256 hash, so a lost key cannot be recovered.
Scopes
Every key has explicit scopes; calls to endpoints outside the granted scopes return 403 insufficient_scope.
| Scope | Grants |
|---|---|
games:read | List the catalog of games. |
content:read | List, retrieve, and read leaderboards for your content. |
content:write | Generate new content and rename it. |
content:delete | Delete content (also removes it from the CDN). |
players:read | List and retrieve embed Players. |
players:write | Update embed Players (auto-republishes to the CDN). |
Mint separate keys per service so each runtime has the minimum scopes it needs.
Revoking
Revoke instantly from Hub → Developers → API keys. Subsequent calls return 401 invalid_api_key.
Storing keys safely
- Never put keys in client-side code, public repos, or browser-side env vars.
- Pass keys at deploy time via your secret manager (AWS Secrets Manager, Vault, Doppler, etc.).
- Rotate keys by creating a new one, deploying it, and revoking the old one.
Every key is associated with a single workspace. Keys do not carry across workspaces — and there is no shared "organization-wide" key.
Legacy X-API-Key header
The legacy header X-API-Key: <api_key> is still accepted, but deprecated. New code should use Authorization: Bearer.