Authentication
Which credential each family of Tanitar routes expects, and where each API is served.
Tanitar routes are grouped into families, and each family accepts exactly one kind of credential. A request that presents the wrong kind is refused; it is never downgraded to an anonymous or different identity.
Route families
| Route family | Credential | Who calls it |
|---|---|---|
/v1/..., the Tournament and Events APIs' unprefixed routes (such as /tournaments, /matches/:matchId/result and /events/:eventId), and /platform/recovery/... | Your API key: Authorization: Bearer defendr_key_… | Your back end |
/dashboard/v1/... | A dashboard session for a member of your organization | The Tanitar dashboard, on behalf of your administrators |
POST /player/v1/sessions | Your dedicated Player-session credential | Your trusted back end, asserting one player |
Other allowlisted /player/v1/... routes | A Player-context bearer token | Your players' apps, on behalf of one player |
API key: your back end
Server-to-server integration uses an API key on every request:
curl "$TOURNAMENT_API_URL/tournaments" \
-H "Authorization: Bearer $TANITAR_API_KEY"The key decides the account the request acts on: there is no account or tenant parameter to send, and a key can never reach another account's data. Its scopes decide which routes it may call. See API keys and scopes.
A missing, malformed, unknown, expired or revoked key gets 401 with ACCESS_CREDENTIAL_INVALID.
If your account is suspended or closed, a valid key gets 403 with ACCESS_ACCOUNT_DISABLED.
Dashboard session: your administrators
The dashboard signs your team members in and calls the /dashboard/v1/... routes for them. You
do not call these routes from your back end; use the dashboard instead. Creating API keys and
registering webhook endpoints are available there. See the dashboard guide.
Player-context bearer: your players
Your players never hold an API key or Player-session credential. After authenticating a Player,
your trusted backend calls POST /player/v1/sessions with its dedicated credential and stable
external Player id. Tanitar returns a short-lived (15-minute) signed JWT, sent as
Authorization: Bearer … on /player/v1/... routes such as GET /player/v1/wallets. A player can
only ever read and act on their own data.
Session creation and credential custody are covered in Player identity.
Private operator and service-to-service surfaces are outside the customer integration contract and are intentionally not documented here.
API base URLs
Each API is served from its own base URL, which Tanitar provides for your environment. The samples
in these docs use one placeholder per API, and read your key from $TANITAR_API_KEY.
| Placeholder | API | Serves |
|---|---|---|
IDENTITY_API_URL | Identity | Player-session creation, memberships and membership tiers, and nickname pricing |
EVENT_API_URL | Events | Events with their tournaments, crew and media, event pages, registrations and badges |
GAME_API_URL | Game | The game catalog and player game statistics |
GAMIFICATION_API_URL | Gamification | Event ingestion, missions, progress, levels, chests, battle-pass seasons, leaderboards |
NOTIFICATION_API_URL | Notification | Player notifications |
REWARD_API_URL | Reward | Currencies, wallets, grants, awards, exchanges, payouts, Web3, and the shop |
TENANT_API_URL | Tenant | API keys, webhooks, Player-session credentials, and dashboard configuration |
TOURNAMENT_API_URL | Tournament | Organizations, tournaments, stages, teams, enrollments, matches, results and evidence |
Set them once in your environment:
export TANITAR_API_KEY="defendr_key_…"
export REWARD_API_URL="https://…"
export TOURNAMENT_API_URL="https://…"No API has a global path prefix. The version is part of each route: most routes start with /v1,
while Tournament routes, Event routes and the /platform/recovery/... routes have none. Always use the path
exactly as documented.