Ability Catalog

Ability strings are the fine-grained permissions you tick when you mint a personal access token. Miss the one an endpoint or tool needs and the request returns TOKEN_MISSING_ABILITY, naming it in error.context.required_ability.

One string, every surfaceCopy Anchor Link

A single ability — say project-subscription-plan:create — is the source of truth in three places:

1. The dashboard, when a human clicks "Create plan".
2. The REST API, in the controller before the mutation runs.
3. The MCP server, inside the tool handler before the action runs.

An MCP tool requires exactly what its REST equivalent requires. Mint for the operations you intend to perform, never for the channel you intend to perform them over. A client connected to the MCP server by signing in acts as the creator themselves and satisfies every ability their team role grants; this catalog governs what a personal access token carries.

FormatCopy Anchor Link

<entity>:<action>, with : as the separator and - inside a multi-word entity or action — project-subscription-plan:view-any.

Most entities carry the five CRUD actions (view-any, view, create, update, delete). Two do not, because their lifecycle is not CRUD:

• team-member — membership is invited and removed rather than created and deleted, and update-role is its own action.
• webhook-delivery — a delivery is a record of something that already happened, so it can only be listed and retry'd.

The catalogCopy Anchor Link

109 ability strings, of which 108 can be granted to a new token.

The Enforced on column says what actually checks each one today:

ProjectsCopy Anchor Link

Project resourcesCopy Anchor Link

Support inboxCopy Anchor Link

TeamsCopy Anchor Link

Roles & groupsCopy Anchor Link

WebhooksCopy Anchor Link

API tokensCopy Anchor Link

PaymentsCopy Anchor Link

PassesCopy Anchor Link

A token holding project-subscription-plan:view-any also satisfies pass-window:view-any, because the window list gated on the plan ability before the pass-window family had a surface of its own; tokens minted for n8n or the MCP docs keep working, and new tokens should carry pass-window:view-any explicitly.

BroadcastCopy Anchor Link

BillingCopy Anchor Link

AccountCopy Anchor Link

AnalyticsCopy Anchor Link

Activity logCopy Anchor Link

Distribution linksCopy Anchor Link

Machine-readable exportCopy Anchor Link

GET https://api.subscriby.net/abilities.json

Regenerated on every deploy from the same enum the application checks against, so it cannot drift. Each entry carries value, category, status and, where one applies, a note.

Choosing abilities when mintingCopy Anchor Link

Least privilege, in practice:

1. Read-only tooling — the :view-any and :view abilities for the entities you read, and nothing else.
2. Automation that creates plans — add project-subscription-plan:create and :update.
3. An assistant over MCP — add every ability for the tools you want it to run. Start with reads; the tools reference maps each tool to its ability.
4. Zapier and n8n triggers — add webhook-endpoint:create and webhook-endpoint:delete; subscribing to events registers and removes an endpoint behind the scenes.
5. A token that mints other tokens — add token:create, and read attenuation first. A token can only grant what it already holds, and can never pass on token:create.

Team and project scope entriesCopy Anchor Link

Alongside abilities, every token carries one required and zero-to-many optional scope entries:

• scope:team:<uuid> — required. Frozen at mint time; the token can never act outside this team.
• scope:project:<uuid> — optional, repeatable. If present, the token is restricted to the listed project ids even when the user owns more projects inside the team.

These are stored in the same array as abilities but are not abilities, and the Tokens API reports them separately under scopes for that reason. See tenancy and scopes for how they combine with tenant isolation at request time.