API Keys
Section 4 — API & Game Key Management
Section 4 — API & Game Key Management
Gamers Lab uses two distinct kinds of keys. They exist for different trust boundaries and must never be confused or merged.
Key Types — Side-by-Side
| Aspect | Tenant API Keys | Game Auth Keys |
|---|---|---|
| Table | bus_tenant_api_keys | bus_game_auth_keys |
| Header | X-API-Key | X-Game-Key |
| Primary use | Read data | Write data |
| Used by | External services | Game servers / clients |
| Direction | Read-only | Write / ingest |
| Trust level | Low | High |
| Granular flags | Yes (flags + profiles) | No (implicit by purpose) |
| Rate limiting | Per-key minute/hour (Lua) | Per-key minute/hour (Lua) |
| Quota enforcement | No | Yes (approximate hard-stop) |
| Environment | Not applicable | dev / prod |
| Typical consumer | BI tools, dashboards | Unity / Unreal / backend |
| Compromise impact | Data leakage | Data poisoning |
Endpoints must enforce:
- Tenant API Keys cannot hit write endpoints, except for the explicit
allowAuthhosted-auth POST allowlist. - Game Auth Keys cannot hit read/analytics endpoints.
If a key works on both paths, the design is wrong.
Both key types record per-request usage to a durable Postgres ledger (bus_api_key_usage, bus_game_key_usage). Each row captures request count, bytes, status code, and billing classification. Game key usage is rolled into hourly summaries for analytics, while quota rollup workers process API key and game key usage for quota evaluation and alerts.