Skip to main content

​
Two auth modes

BlitzBoard uses different credentials for management vs integration: Public routes only accept keys that start with bb_live_. A normal login JWT is rejected on the public API. Public routes expect:
This is not the same as Stripe’s secret key. Stripe uses its own secrets and webhook signatures. BlitzBoard public auth is only for /v1/blitz-api.

​
Who can manage keys

Only a BlitzBoard super admin (isSystemAdmin) via the admin backend. Organization creators and organization admins cannot create or manage API keys.

​
Generate an API key

A BlitzBoard super admin issues a key for an organization from the admin side (POST /api-keys on the admin API) with:
Copy the full bb_live_... value when it is shown — it is only displayed once. Audit fields on the key:

​
Manage keys (admin API)

Key management lives on the admin backend, not the public/main app API.

​
Create

POST /api-keys Response includes apiKey once, plus id, keyPrefix, organizationId, createdBy, and status.

​
List

GET /api-keys?organizationId=<orgId>

​
Revoke

DELETE /api-keys/:id

​
Rotate

POST /api-keys/:id/rotate Returns a new plaintext apiKey once; the previous secret stops working. createdBy stays the original admin; lastRotatedBy / rotatedAt record who rotated.

​
Organization scope

Every key is bound to one organizationId. On public requests:
  1. ApiKeyGuard validates the Bearer key and loads the organization creator as the acting user (for team permissions), plus org context from the key.
  2. Team create/list inject that org automatically.
  3. Routes with teamId ensure the team belongs to the key’s organization.
A valid key for Org A cannot read or mutate Org B’s teams, players, or schedules.