List a subscription's grants
/v1/subscriptions/{subscription}/grants in the Subscriptions API.
curl https://api.subscriby.net/v1/subscriptions/$SUBSCRIPTION_ID/grants \ -H "Authorization: Bearer $SUBSCRIBY_TOKEN"Every grant the purchase holds, one per resource and dated window, oldest first. Never paginated.
A grant is the access ledger's record that a purchase admits its holder to one resource: one row per resource, and per dated window for a pass. It says which connector gave the access, how (mode), where it stands (state) and, when it failed, why. Read it to know whether a member is actually in the channel rather than inferring it from the payment status.
modeisbearer_link(a personal invite link the member comes through),membership(the connector added the member itself),role(a role was assigned) orcreator_task(the creator has to do something by hand).stateispending_identity(the member has not linked an account on that connector yet;member.resource_pendingwas raised, and the grant is issued the moment they connect one),pending(issued, not yet used),held(issued ahead of a pass window and released when it opens),granted,revokedorfailed.identity_idis the connector account admitted, the same id the member's identities endpoint returns, ornullwhile none is linked or for a hand-arranged perk.referenceis the connector's handle on the grant (the invite link on a connector that grants by link),nullbefore anything was issued. Treat it as a secret: whoever holds a bearer link can use it.- A
failedgrant carriesfailure_kind(unreachable,not_permitted,target_missing,rate_limited,configuration,transient,other) andfailure_detail, the sentence the creator sees in the dashboard.
The ledger is written by the same job that mints invite links, so a purchase's grants appear moments after member.resource_added fires; a revoked link stays as a revoked row rather than disappearing, so history is never lost.
Requires ability
The token must hold this ability, or the call is refused with 403.
MCP tool
Runs the same action from an agent, behind the same ability.
Authorization
bearerToken A personal access token minted on the dashboard under Settings, then Tokens, sent as Authorization: Bearer sbt_live_…. The token carries the abilities each endpoint lists under Requires ability and is frozen to one team.
In: header
Path Parameters
The subscription, resolved by the route binder.
uuidResponses
200OKapplication/json
Array of AccessGrantResource
401UnauthorizedAUTHENTICATION_REQUIREDapplication/json
The request carries no bearer token, or one that is revoked, malformed, or minted for another environment (an sbt_test_ token on production).
403ForbiddenTOKEN_MISSING_ABILITYapplication/json
The token is valid but does not carry the ability this endpoint requires; error.context.required_ability names the one to grant. An endpoint that also checks who owns a row or which tier the account is on answers FORBIDDEN, TEAM_TIER_REQUIRED or CONNECTOR_TIER_REQUIRED with the same status, and says so in its own description.
404Not foundRESOURCE_NOT_FOUNDapplication/json
An id in the path names nothing the token can see. TENANT_MISMATCH: the project sits outside the token's scope:project: allow-list, or the token carries no team scope. Both answer 404 rather than 403 so that existence outside the token's scope cannot be inferred.
429Too many requestsRATE_LIMITEDapplication/json
The token has spent its 300 requests a minute or 10,000 an hour; Retry-After says when the next one is accepted.
How is this guide?
Last updated on