Skip to main content

Base URL and path

Mintlify “Try it”: playground requests are proxied through Mintlify (api.playground.proxy: true) so the browser does not hit sandbox CORS. Swagger at https://sandbox.blitzboardstats.com/api/docs calls the API same-origin and does not need that proxy.

Organization scope

  • Keys are org-scoped, not “everything the user can see.”
  • GET/POST /v1/blitz-api/teams always use the key’s organization.
  • Any teamId must belong to that organization or the request is forbidden.

Rate limiting

Public controllers are throttled at 100 requests / 60 seconds. Exceeding the limit returns a throttle error; back off and retry.

Idempotency key (idem-key)

An idempotency key is a client-generated string that uniquely identifies one create intent. The API stores it on the created player so the same write cannot be applied twice.

Where it is required

Only player create:
Missing either header → 400 (idem-key is required in the header).

Generate a key

Use the generator below to create an idem-key you can paste into Try it or curl.

What to send

  • Any non-empty string that is unique per create intent (UUID recommended).
  • Reuse the same key only when retrying the same create (network timeout, unclear response).
  • Use a new key for every new player.
You can also generate offline:

What happens on reuse

If a player was already created with that idem-key, a second request with the same key returns 409 Conflict (Idempotency key already used) and does not create another player. That protects against accidental duplicates. It does not replay the original success body — treat 409 as “this create already succeeded; look up the player or use a new key for a different player.”

Request ID

Public routes attach a request id (middleware) for tracing. Include it when contacting support about a failed call.

Errors

Errors follow the platform shape, for example:
Common API-key messages:

Permissions

After the API key is accepted, team-level role checks still apply for many player and schedule operations (same permission model as the main app). The acting user is the organization creator for the key’s organization (not the Blitz admin who issued the key).