Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.flexslot.gg/llms.txt

Use this file to discover all available pages before exploring further.

Scopes are how your app tells Flexslot — and the user — exactly what it wants to do. Each scope is a short, colon-separated string. You request them as a space-separated list on the /authorize request:
scope=decks:read sideboards:write guides:read
The user sees a humanized version on the consent screen.

Catalog

Scopes are additive and minimum-necessary. Request only what you need for the operation in front of the user. You can request more scopes later via incremental authorization (start a new flow with the additional scopes).

Decks

ScopeGrants
decks:readList the user’s decks, read deck details, read cards, read deck metadata
decks:writeCreate, update, and delete the user’s decks. Modify cards. (Implies decks:read.)

Sideboards

ScopeGrants
sideboards:readList the user’s sideboards, read sideboard contents and matchup plans
sideboards:writeCreate, update, and delete sideboards. Modify matchup plans. (Implies sideboards:read.)

Sideboard Guides

ScopeGrants
guides:readRead the user’s sideboard guides, including matchup write-ups and strategy notes
guides:writeCreate, update, and delete sideboard guides. Modify matchup notes. (Implies guides:read.)

Cards

ScopeGrants
cards:readLook up cards in the Flexslot card database (autocomplete, batch fetch, card details)
cards:read does not access any user-specific data. It’s the same read-only card data available on the public site. Most integrations need this alongside decks:read because deck contents reference cards.

Exports

ScopeGrants
exports:readGenerate Excel, DOCX, and PDF exports of the user’s decks and sideboard guides

How scope strings combine

Request multiple scopes by separating them with spaces (which are %20 once URL-encoded):
scope=decks:read sideboards:read guides:read cards:read
A scope like decks:write includes decks:read — you don’t have to request both. But explicitly requesting both is harmless and makes the consent screen unambiguous.

What the user sees

For scope=decks:read sideboards:write, the consent screen shows:
Quickstart Test wants to:
  • Read your decks
  • Manage your sideboards (create, edit, delete)
Phrasing comes from a Flexslot-controlled catalog. You can’t customize the text.

Down-scoping

Flexslot may grant fewer scopes than you requested. The /token response always tells you which scopes were actually granted:
{
  "access_token": "fst_at_…",
  "scope": "decks:read sideboards:read",
  "...": "..."
}
If the user denied a scope mid-consent (some UI flows allow per-scope toggles), the scope field in the response will reflect what they approved. Check it. Don’t assume you got everything you asked for.

Scope enforcement on the API

The resource server checks scopes per-endpoint. A token with only decks:read calling POST /decks/ gets:
HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer realm="flexslot",
  error="insufficient_scope",
  error_description="Requires scope: decks:write",
  scope="decks:write"
When you see insufficient_scope, the fix is not to retry — it’s to start a new authorization flow that requests the missing scope.

Incremental authorization

Instead of requesting every possible scope on first login, start with the minimum and request more when you need them.
1

First login: minimum scopes

scope=decks:read — just enough to show the user their decks.
2

User clicks Export

Now you need exports:read. Start a new flow with scope=decks:read exports:read.
3

User keeps using the app

The new token has both scopes. You don’t lose the user’s prior consent — Flexslot remembers it.
This pattern has two big wins:
  • Trust: users are warier of apps that demand everything up front
  • Recovery: if a scope check fails on the API, you have a clear path forward
Don’t request scopes you might use someday. The minimum-necessary rule is enforced socially (users notice, write-ups happen) and reputationally. Pages with sprawling consent screens convert worse.

Scope vs role

Scope is what the app can do. The user’s role on Flexslot still controls whether they’re allowed to do it at all. A free-tier user’s token with decks:write can’t, for example, exceed the free-tier deck limit. The 403 comes from the resource server with a different error than insufficient_scope.

Future scopes

We add scopes when we add public API surface. If you need access to a Flexslot capability that doesn’t have a scope yet, open a feedback ticket — these docs and the scope catalog are kept in sync.