---
title: "Mint a token"
method: POST
path: "/v1/tokens"
tags: ["Tokens"]
---

# Mint a token

`POST /v1/tokens`

## Request

- Base URL: `https://api.subscriby.net`
- URL: `https://api.subscriby.net/v1/tokens`
- Auth: HTTP bearer

```bash
curl -X POST https://api.subscriby.net/v1/tokens \
  -H "Authorization: Bearer $SUBSCRIBY_TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "Nightly reconciliation",
        "team_id": "a83f0d51-4c92-4b7e-8615-2fd9e70a3c86",
        "abilities": ["project-subscription:view-any", "payment:view-any"]
      }'
```

`token` sits alongside `data`, not inside it, the same shape webhook endpoints use for their one-time signing secret. Store it before you do anything else; there is no endpoint that will hand it back. Minting is deliberately not offered as an MCP tool.

**`team_id` is required here, and only here.** Everywhere else in v1 the team comes from the calling token's frozen scope and a `team_id` in the body is ignored. Minting is the exception: a token is created **for** a team, and you may belong to several. The minted token gets `scope:team:<team_id>` automatically. It cannot be widened later.

> **A token can never mint a stronger token.** The abilities you request must be a **subset** of the abilities the calling token holds, and `token:create` is withheld unconditionally from anything minted this way.

Minting used to be dashboard-only precisely so a leaked automation token could not spin up a higher-privilege one. That concern is real, and attenuation is the answer to it rather than a retreat from it: a compromised credential can produce nothing its holder could not already do directly. `token:create` is withheld on top of the subset rule for a separate reason: inherited, it would leave an unbounded ladder of tokens descending from one leak, with no single revocation that ends the chain. A human in the dashboard is not attenuated. They authenticated with a password and a second factor, not with a bearer string, so they can grant anything in the catalog.

If the calling token carries a **deprecated** coarse ability, it may still mint the precise abilities that ability covers; the split does not shrink what an existing token can delegate.

Asking for more than you hold returns `422`; `context.abilities` echoes back what you asked for, not what was refused, and the refused ones are named in `message`:

```json
{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "A token cannot grant abilities it does not hold: coupon:delete, project:delete.",
    "context": {
      "abilities": ["coupon:delete", "project:delete", "project:view-any"]
    }
  }
}
```

A retired ability keeps working on tokens that already carry it, but no new token can be given one. This is a field-level failure, so every offending entry in the array is reported at once under `fields`, and the message names the replacements; an ability that is simply unknown gets a different message pointing at the catalog, because a typo and a retirement need different fixes:

```json
{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "webhook-endpoint:manage is retired and cannot be granted to a new token. Use webhook-delivery:retry, webhook-delivery:view-any, webhook-endpoint:create, webhook-endpoint:delete, webhook-endpoint:update, webhook-endpoint:view, webhook-endpoint:view-any instead.",
    "fields": {
      "abilities.0": [
        "webhook-endpoint:manage is retired and cannot be granted to a new token. Use webhook-delivery:retry, webhook-delivery:view-any, webhook-endpoint:create, webhook-endpoint:delete, webhook-endpoint:update, webhook-endpoint:view, webhook-endpoint:view-any instead."
      ]
    }
  }
}
```

## Headers

- `Idempotency-Key` string, uuid, required

## Request body

- StoreTokenRequest: A token to mint: its label, the abilities it holds and the team it is minted for. The abilities must be a subset of the calling token's, and `token:create` is never granted this way.
  - `name` string, required: A label for the token, up to 255 characters, shown on Settings → API Tokens.
  - `abilities` string[], required: The abilities the token holds, at least one. Each must be one the calling token holds itself (attenuation), and `token:create` is withheld unconditionally.
  - `team_id` string, uuid, required: The team the token is minted **for**; it receives `scope:team:<team_id>` automatically and cannot be widened later. Must be a team the caller owns or belongs to. Required here, unlike everywhere else in v1 where the team comes from the calling token's scope.

## Response `201`

The token resource plus the plaintext, as a 201.

- object
  - `data` TokenResource, required: One of the caller's personal access tokens, without its value. The plaintext exists exactly once, in the response that minted it.
    - `id` string, required: The token's id: an **integer** serialised as a string, the one identifier in the platform that is not a UUID.
    - `name` string, required: The label the token was minted with.
    - `abilities` string[], required: The gate abilities only; the scope tuples are split out into `scopes`.
    - `scopes` object, required: The token's confinement, read out of its `scope:team:` and `scope:project:` abilities as structure rather than opaque strings.
      - `team_id` string, required: The team the token is scoped to; null for a token minted without a team scope.
      - `project_ids` string[], required: The projects the token is confined to; empty when it reaches every project of the team.
    - `abilities_count` integer, required: How many gate abilities the token holds, bookkeeping excluded.
    - `last_used_at` string, nullable, required: When the token last authenticated a request, ISO 8601; null until it has.
    - `expires_at` string, nullable, required: When the token stops working, ISO 8601; null for a token that does not expire.
    - `created_at` string, nullable, required: When the token was minted, ISO 8601.
  - `token` string, required: The plaintext token, `sbt_<env>_<id>_<secret>`, returned exactly once. Store it before anything else.

## Other responses

- `400`: `IDEMPOTENCY_KEY_MISSING`: every write needs an `Idempotency-Key` header. Send a fresh UUID per distinct operation.
- `401`: `AUTHENTICATION_REQUIRED`: the request carries no bearer token, or one that is revoked, malformed, or minted for another environment (an `sbt_test_` token on production).
- `403`: `TOKEN_MISSING_ABILITY`: 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.
- `409`: `IDEMPOTENCY_KEY_REUSED`: the key was already used in the last 24 hours with a different request body.
- `422`: `VALIDATION_FAILED`: the payload broke a rule, and `error.fields` maps each offending key to its messages. A refusal from the domain, such as a plan that cannot go on sale or a member who cannot be removed, uses the same code with `error.message` saying why and no `fields`. On this endpoint: `VALIDATION_FAILED`: when a requested ability is not held by the calling token, `token:create` is requested, `team_id` is not a team the caller owns or belongs to, an ability is retired or unknown, or `abilities` is empty.
- `425`: `IDEMPOTENCY_REPLAY_IN_PROGRESS`: the first request with this key is still running; retry in a few seconds and the original response is replayed.
- `429`: `RATE_LIMITED`: the token has spent its 300 requests a minute or 10,000 an hour; `Retry-After` says when the next one is accepted.

---

[API](https://skmtc.dev/memberpass/apis/subscriby-rest-api.md) · [All operations](https://skmtc.dev/memberpass/apis/subscriby-rest-api/llms.txt) · [OpenAPI document](https://skmtc.dev/memberpass/apis/subscriby-rest-api/revisions/59c4df91d764?raw)