Skip to main content
New partner? OAuth requires a registered partner row. Apply for partner access first, then come back here to wire your client.

What is OAuth at Flexslot?

OAuth 2.0 is how third-party apps act on behalf of a Flexslot user without ever seeing that user’s password. Your app sends the user to flexslot.gg, the user clicks “Allow”, and you get back an access token scoped to exactly what you asked for. If you’re building a deck tracker, a tournament platform, a Discord bot, a metagame analyzer, or any tool that needs to read or write a user’s decks, sideboard guides, or strategy content, OAuth is what you want.

Claude Code Skill

Let Claude Code build your integration for you

Quickstart

Get your first integration working in 10 minutes

Code samples

Drop-in Node.js, Python, and curl examples

Authorization Code Flow

The full end-to-end flow with PKCE

Scopes

Every scope and what it grants

Which auth method should I use?

Flexslot supports three ways for an external system to authenticate. Pick the one that matches your situation, not the one that’s easiest to ship.
MethodActs asUse whenDon’t use when
OAuth 2.0A specific Flexslot user (with their consent)Your product is used by multiple Flexslot users and each one connects their own accountYou need server-to-server access that isn’t tied to a user
Personal Access Token (PAT)A single user (yourself)You’re scripting against your own account or running a one-off integrationYou’re building a product other Flexslot users will sign into
HMAC Webhook SigningFlexslot itself (verifying us)Receiving webhook callbacks from FlexslotCalling our API
If you’re not sure: use OAuth. PATs are only appropriate for personal scripts; HMAC is only for verifying inbound webhooks. Everything else is OAuth.

Terminology

A few terms you’ll see throughout these docs. We use the standard OAuth 2.0 vocabulary from RFC 6749.
The Flexslot user whose decks, guides, or content your app wants to access. They’re the one clicking “Allow” on the consent screen.
Your application. Registered with Flexslot via the partner admin and identified by a client_id.
Flexslot. Specifically the endpoints under https://api.flexslot.gg/api/public/v1/oauth/.
Flexslot’s REST API at https://api.flexslot.gg/api/public/v1/.... Accepts the access tokens issued by the authorization server.
A short-lived (1 hour) opaque string that proves your app is acting on behalf of a user. Sent as Authorization: Bearer <token>.
A longer-lived token used to get a new access token when the current one expires. Rotates on every use — store the new one.
A space-separated list of permissions your app requests, e.g. decks:read sideboards:write. The user sees these on the consent screen.
Proof Key for Code Exchange. A required security mechanism that binds the authorization code to your app, even if the code is intercepted. Mandatory for all clients.

Endpoints

The API endpoints (token, introspection, revocation) live under https://api.flexslot.gg. The authorization endpoint — the only one a browser navigates to — is the user-facing consent screen at https://flexslot.gg/oauth/authorize. We publish a discovery document (RFC 8414) listing the exact URLs; fetch it programmatically rather than hard-coding hosts.
EndpointURLPurpose
Discoveryhttps://api.flexslot.gg/.well-known/oauth-authorization-serverLists all endpoints and supported capabilities
Authorizationhttps://flexslot.gg/oauth/authorizeWhere you send the user’s browser to consent
Tokenhttps://api.flexslot.gg/api/public/v1/oauth/tokenExchange code for tokens, or refresh tokens
Introspectionhttps://api.flexslot.gg/api/public/v1/oauth/introspectCheck whether a token is still valid (RFC 7662)
Revocationhttps://api.flexslot.gg/api/public/v1/oauth/revokeRevoke a token on logout (RFC 7009)
The authorization endpoint is on flexslot.gg, not api.flexslot.gg — it’s a web page the user’s browser opens, not an API call. The iss value returned on the callback is still the API issuer https://api.flexslot.gg; validate against that.

What’s supported

CapabilitySupportedNotes
Authorization Code GrantYesThe only user-facing grant we support
PKCE (S256)RequiredAll clients, public and confidential
Refresh Token RotationYesNew refresh token on every refresh
Token IntrospectionYesRFC 7662
Token RevocationYesRFC 7009
Sender-Constrained Tokens (DPoP)Yes (opt-in)See DPoP
Client Credentials GrantNoUse a PAT instead
Implicit GrantNoDeprecated by RFC 9700
Resource Owner Password GrantNoForbidden by RFC 9700
Device Authorization GrantNoNot currently supported

Token lifetimes

TokenLifetimeRotates?
Authorization code10 minutesSingle use
Access token1 hourNo (request a new one via refresh)
Refresh token30 daysYes — every use
Refresh tokens rotate. Every time you call /token with grant_type=refresh_token, you get back a new refresh token and the old one is invalidated. Store the new one immediately. Replaying an old refresh token revokes the entire grant. See Security.

Where to go next

Quickstart

Register a client and run the flow with curl

Security best practices

PKCE, state, redirect URIs, refresh rotation

Error reference

Every error code and how to fix it

Migrating from PAT

Already using a PAT? Add OAuth alongside.