Management API

This article covers the tokens that let a script, a CI job or an AI agent act on your account — your listings, Worker code, pricing and analytics, and your own subscriptions and API keys — without your login.

The Management API is the same REST the API Studio and the Workspace use. A management token stands in for your session on those routes, and nothing else changes: the same validation, the same ownership checks, the same audit trail. What the token may do is set by its scopes, and optionally limited to some of your APIs or projects.

Management tokens are not API keys

	API key (`jk_…`)	Management token (`jm_…`)
Who uses it	A consumer calling APIs they subscribe to	You, or a script or agent working for you
Where it is checked	The gateway	`app.jojapi.com` only
What it can reach	The APIs the key is allowed to call	Your listings, code, pricing, analytics and subscribers; your subscriptions, projects and API keys — by scope
What it can never reach	—	Top-ups, adding or removing payment methods, the billing profile; your profile and sign-in; members; other tokens; deleting an API, payouts and verification

Give each script or agent its own token with only the scopes it needs, set an expiry, and revoke it when the job is done.

Create a token

Open Settings › Tokens (Settings is in the user menu, top right) and choose Create token:

Name it after what will use it.
Pick the scopes, or start from a template and adjust it.
Limit it to some of your APIs or projects if the job touches only those (optional).
Set a spend limit if it has subscriptions:write.
Set an expiry, up to a year.

The token is shown once. Store it where your script or agent reads secrets from, never in a repository. A live token can be edited later (scopes, limits, spend limit) without changing its value.

Templates

Template	Scopes	For
Read only	every read scope except `request-logs:read`, `keys:read`, `earnings:read` and `billing:read`	dashboards, reporting, an agent that only looks
CI: preview deploys	`code:read`, `code:write`, `variables:write`, `resources:write`	a preview deployment per pull request; promoting stays with you
CI: production deploys	the preview set plus `deployments:promote`	Deploy from GitHub with production on merge
Docs agent	`apis:read`, `apis:write`, `endpoints:write`	keeping descriptions, parameters and examples up to date
Analytics agent	`apis:read`, `analytics:read`, `subscribers:read`	traffic and customer reports
Consumer agent	`subscriptions:read`, `subscriptions:write`, `keys:read`, `keys:write`, `usage:read`	an agent that subscribes to APIs and manages its keys; needs a spend limit, and pays from the wallet unless you add `payment-methods:charge`

Scopes

Scopes are resource:action. A route needs all the scopes listed for it; a few writes need one more scope depending on what they change, noted below.

Your APIs

Group	Scope	Allows
Listing	`apis:read`	Your APIs, endpoints, docs, plans, billable objects and FAQs
	`apis:write`	API details, about text, logo and FAQs; creating an API
	`apis:publish`	Visibility, the Requests switch and marketplace submission
	`endpoints:write`	Endpoints, parameters, responses, groups and their order
	`imports:write`	Imports from OpenAPI, Postman, RapidAPI and Apify
Pricing	`plans:write`	Plans, quotas, rate limits, plan features, custom plans for one customer
	`metering:write`	Billable objects, what endpoints cost, usage sources, agent prices and agent payments
Code and deploy	`code:read`	Template, files, variable names, resources, shares and deployments
	`code:write`	Template, files and mode saves, which create preview deployments
	`deployments:promote`	Promote, roll back, deploy pending changes, any save with `production: true`, deployment access, Keep active and archive
	`variables:write`	Variables and secrets (into production only together with `deployments:promote`)
	`resources:write`	Add resources and bind shared ones
	`resources:delete`	Remove resources; their data is lost
	`shares:write`	Share resources with other APIs; accept, decline and revoke shares
	`runtime:write`	Worker settings (console logging)
	`targets:write`	The gateway prefix: a second host name for an API, live at once
Observability	`analytics:read`	Traffic, uptime, latency and compute usage
	`request-logs:read`	Request logs of your APIs: your consumers’ IP addresses, headers and bodies. Sensitive
	`runtime-logs:read`	Console output and runtime errors
Customers	`subscribers:read`	Subscribers and their usage
	`subscribers:write`	Cancel subscriptions, transfer them to other plans, grant quota
Money	`earnings:read`	Sales and payouts

Your Workspace and account

Group	Scope	Allows
Workspace	`subscriptions:read`	Your own subscriptions and the plan transfers offered to you
	`subscriptions:write`	Subscribe, cancel, change plan, pay what is due — within the token’s spend limit, from the wallet
	`keys:read`	Projects and API keys. Key values come masked unless asked for. Sensitive
	`keys:write`	Create, label, restrict and delete projects and API keys
	`usage:read`	Your own usage, spend and request logs
	`messages:read`, `messages:write`	Your DM inbox; sending DMs
Account	`members:read`	Members, invitations, roles, teams and grants of an organization
	`billing:read`	Balance, invoices, payment methods and the billing profile
	`payment-methods:charge`	Charge your saved payment methods when the wallet does not cover a payment, the way a renewal does, within the token’s spend limit. Sensitive
	`activity:read`	Your account’s activity log

Settings › Tokens marks keys:read, request-logs:read and payment-methods:charge as sensitive: a leaked token with one of them leaks your API keys or your consumers’ data, or can charge your cards up to its spend limit.

Never on a token

Some actions stay with a person signed in to the Studio, whatever scopes a token holds:

Money in and out of your account: top-ups, auto top-up, adding, removing or ordering payment methods and the billing profile; card, PayPal and crypto checkouts.
Your account itself: profile, username and photo; sign-in, password, email, social connections and two-factor authentication.
Tokens and people: creating, changing or revoking management tokens; organization members.
Owner actions: deleting an API, payout methods, verification and accepting the provider terms.

Limit a token to some APIs or projects

A token can be limited to some of your APIs, some of your projects, or both:

APIs limit the routes that act on one of your APIs (listing, pricing, code, observability, customers). Every other API is refused with resource_not_allowed.
Projects limit the routes that act on projects and their API keys, and usage by key. Keys of other projects are refused.
Lists narrow. ProviderApis, projects and api-keys list only what the token may use.
Routes that cover everything are refused to a limited token: for an API limit, the Studio dashboard, traffic and uptime totals, transactions, payouts, subscribers and creating an API; for a project limit, the Workspace dashboard and creating a project. Routes with an optional filter (api for Studio analytics and request logs, project or api_key for usage) work when the request names one the token may use.

Paying with a token

A token with subscriptions:write can subscribe to plans, pay a past-due subscription and accept a plan transfer. It pays like this:

From the wallet first, in USD. Top up the wallet in the Workspace before an agent needs it.
Saved payment methods only with payment-methods:charge. When the wallet does not cover a payment, a token with this scope charges your saved payment methods in their order, without you, the way a renewal is charged; a card that asks for 3-D Secure fails. Without the scope the token pays from the wallet only.
Within its spend limit per calendar month, counted from everything the token paid — wallet and cards — net of refunds. The limit is a setting of the token, required with subscriptions:write; 0 allows free and pay-as-you-go plans only.
You hear about it. Every subscription a token makes emails you with the token’s name and its spend this month.

The subscriptions themselves are your account’s: they renew and are billed like any other subscription, whichever token made them. Pay-as-you-go plans cost nothing to subscribe to; their usage is taken from the wallet as requests are made. A payment the token cannot make is refused before anything changes:

`status`	Meaning
`spend_limit_exceeded`	The payment would take the token past its limit; the answer has `price_usd`, `spend_limit_usd` and `spent_this_month_usd`
`insufficient_balance`	The wallet does not cover the price and the token has no `payment-methods:charge` (`balance_usd`, `price_usd`)
`payment_error`	The wallet does not cover the price and no saved payment method could be charged
`usd_only`	The plan is billed in a currency other than USD
`spend_limit_required`	The token has no spend limit

API keys and agents

Tokens with keys:read can read your API keys, but the answers keep the values out of sight unless a request asks for them:

Masked by default. GET v1/api-keys returns each key’s preview as jk_••••••••abcd with masked: true, and create-api-key returns the new key the same way.
Revealed on request. reveal=true (in the query string of a GET, in the JSON body of a POST) returns the values. Only a token with keys:read gets them; keys:write alone never does.
Keys by id. Every key carries an id (n…). delete-api-key, set-api-key-label, set-api-key-restrictions and set-api-key-gateway-headers take that id in place of the key, so managing keys never needs their values.

For agents: use a value only where it is needed, and keep it out of your context. The CLI writes a new key straight to a file without printing it — jojapi keys create --to-env-file .env — so your code can read it from there. Ask for reveal=true only when a person needs to see the key, and never paste a key into a prompt, a log or an issue.

Check a token

GET v2/management-token describes the token that calls it — every token can call it:

curl https://app.jojapi.com/rest/v2/management-token \
  -H "Authorization: Bearer jm_…"

{
  "status": "success",
  "token": {
    "id": "n4f2a91c0", "name": "Consumer agent", "last4": "Nkqd",
    "scopes": ["subscriptions:read", "subscriptions:write", "keys:read", "keys:write", "usage:read"],
    "legacy": false,
    "restrictions": { "apis": null, "projects": [{ "id": "proj_01m52erdhgfgws6zw45nrhsy79", "name": "Agents", "deleted": false }] },
    "spend": { "limit_usd": 50, "spent_this_month_usd": 17.5, "remaining_usd": 32.5 },
    "created_at": "2026-10-16 16:31:51", "expires_at": "2027-01-14 16:31:51", "last_used_at": "2026-10-16 16:40:02"
  },
  "account": { "id": "x7k2", "username": "my-team", "name": "My Team", "kind": "human" },
  "wallet": { "balance_usd": 82.5 }
}

wallet is there for tokens with subscriptions:write or billing:read. jojapi whoami prints the same.

Calling it

The jojapi CLI wraps these routes in commands with previews and confirmations. To call the routes directly, send the token as a bearer token to the REST routes under https://app.jojapi.com/rest/. If a proxy in front of your script strips Authorization, the header X-Management-Token: jm_… is accepted too. Answers are JSON with a status field; the HTTP status is 200 for every answer the application produced, so read status, not the code:

`status`	Meaning
`success`	Done; the rest of the body is the route’s answer (`GET v1/api-keys` answers `status: true`)
`unauthorized`	Bad, expired or revoked token, or a route a token cannot call (`route` says which; a token from before the current scopes also gets `required_scopes`)
`insufficient_scope`	The token lacks a scope the route, or this particular change, needs; `required_scopes` and `token_scopes` say what is missing
`resource_not_allowed`	The token is limited to other APIs or projects
anything else	The route’s own validation, exactly as the Studio would show it

Tokens created before these scopes

Tokens created before these scopes hold the earlier ones and keep exactly the access they had, so CLI logins, CI secrets and jojapicom/deploy-action need no change. Settings › Tokens marks them Legacy scopes and offers Upgrade scopes: it proposes the current scopes that cover everything the token can do today, you remove what it does not need, and the token keeps its value.

Earlier scope	Covers today
`listings:read`	`apis:read`
`listings:write`	`apis:write`, `apis:publish`, `endpoints:write`, `imports:write`, `plans:write`, `metering:write`, `targets:write`
`plans:write`	`plans:write`, `metering:write`, `subscribers:write`
`analytics:read`	`analytics:read`, `request-logs:read`, `earnings:read`
`subscriptions:read`	`subscribers:read`, `subscriptions:read`
`code:read`	`code:read`, `runtime-logs:read`, `analytics:read`
`code:write`	`code:write`, `deployments:promote`, `variables:write`, `resources:write`, `resources:delete`, `shares:write`, `runtime:write`

New tokens get the current scopes only.

Routes

Every route takes and returns JSON. GET routes take their parameters in the query string; POST routes take a JSON body. slug is an API’s slug — the last part of its Studio URL.

Listings

Route	Scope	What it does
`GET v2/ProviderApis`	`apis:read`	Your APIs
`GET v2/provider-api?slug=`	`apis:read`	One API with its endpoints
`GET v2/provider/api-endpoint?slug=&method=&url_path=`	`apis:read`	One endpoint in full: parameters, body, responses
`GET v2/studio/api-plans?slug=` · `api-objects?slug=` · `api-faqs?api_slug=`	`apis:read`	Plans, billable objects, FAQs
`GET v2/api-page?slug=`	none; `apis:read` for your own API	The marketplace page (your own API with hidden endpoints)
`POST v2/provider/add-api`	`apis:write`	Create an API
`POST v2/update-api-details` · `update-api-about`	`apis:write` (+ `apis:publish` to change visibility or the Requests switch)	Name, description, logo, visibility, about text
`POST v2/provider/listing-resubmit`	`apis:publish`	Tell the reviewers a warned listing is fixed
`POST v2/provider/add-endpoint` · `provider/update-endpoint-details` · `provider/delete-endpoint` · `provider/duplicate-endpoint`	`endpoints:write` (+ `metering:write` to change what the endpoint costs)	Endpoints
`POST v2/provider/update-endpoint-deprecation`	`endpoints:write`	Deprecate an endpoint (date, removal date, replacement) or undo it; see Deprecating an Endpoint
`POST v2/update-url-parameters` · `update-header-parameters` · `update-path-parameters` · `update-endpoint-body`	`endpoints:write`	An endpoint’s parameters and body
`POST v2/update-endpoint-responses` · `upsert-endpoint-response`	`endpoints:write`	Documented responses and examples
`POST v2/create-api-endpoint-group` · `update-endpoint-group` · `delete-endpoint-group` · `move-endpoint-to-group` · `set-group-order` · `update-endpoint-orders`	`endpoints:write`	Grouping and order
`POST v2/studio/create-api-faq` · `update-api-faq` · `delete-api-faq` · `update-api-faq-orders`	`apis:write`	FAQs
`POST v2/set-custom-gateway-prefix`	`targets:write`	A second host name for the API, `<prefix>.jojapi.net`

update-endpoint-details replaces the endpoint’s details and billing together. Sending the stored billing back unchanged, as the CLI does when it renames an endpoint, needs endpoints:write only.

Imports — publishing an OpenAPI document

The fastest way to keep a listing in step with your code is to publish its OpenAPI document. An import never touches an existing endpoint’s blocked/hidden flags, its group or its plans unless you ask it to.

Route	Scope	What it does
`POST v2/import/preview`	`imports:write`	`{slug, bundle}` → what would be new, changed, unchanged and missing
`POST v2/import/apply`	`imports:write` (+ `plans:write` with `import_plans` or `publish_plans`)	`{slug, bundle, new_hidden, overwrite_changed, hide_missing, update_meta, use_groups, import_plans, publish_plans}` → writes the diff in one transaction
`POST v2/import/fetch` · `import/upload` · `import/fetch-rapidapi` · `import/fetch-apify`	`imports:write`	Fetch or upload a source document into a snapshot

bundle is a JSON string in the import engine’s source-agnostic shape:

{
  "meta": { "name": "…", "description": "…" },
  "endpoints": [{
    "method": "GET", "url_path": "/v1/serp", "name": "Full SERP", "description": "…", "group": "",
    "url_parameters": [{ "key": "query", "name": "", "description": "…", "example": "best running shoes",
                         "value_type": "string", "enum_values": null, "default_value": "", "required": true }],
    "header_parameters": [], "path_parameters": [], "body": null,
    "responses": [{ "status": "200", "description": "…", "schema": null,
                    "examples": [{ "name": "success", "summary": "", "description": "", "example": "{…}" }] }]
  }]
}

value_type is one of string, enum, number, integer, boolean, date, time, object, array, geopoint. Preview first, read the diff, then apply.

Pricing

Route	Scope
`POST v2/studio/create-api-plan` · `update-api-plan` · `delete-api-plan` · `update-plan-display` · `add-api-plan-object` · `set-user-custom-api-plan`	`plans:write`
`POST v2/studio/set-api-features`	`plans:write`
`POST v2/studio/create-object` · `update-object` · `delete-object`	`metering:write`
`POST v2/provider/bulk-update-endpoint-billing` · `provider/bulk-update-endpoint-agent-price` · `provider/set-api-agent-payments`	`metering:write`

create-api-plan answers the new plan as plan: {slug, type, blocked}. A public plan must fit the pricing page: at most 10 public plans per API, one of them pay-as-you-go. This applies both when you create a plan as public and when update-api-plan makes a private plan public; over the limit the status is public_plans_limit_reached. Public plans with the same name share a card on the pricing page, so two of them can’t have the same period and rate limit: create-api-plan, update-api-plan and update-plan-display answer plan_card_conflict to a change that would make such a pair (see How plans appear on the pricing page).

Analytics, customers and earnings

Route	Scope
`GET v2/studio-analytics-api[?api=]` · `provider-apis-traffic` · `studio-low-uptime-endpoints`	`analytics:read`
`GET v2/provider/endpoint-callers?slug=&method=&url_path=[&days=30]`	`analytics:read`
`GET v2/request-logs-studio[?api=]`	`request-logs:read`
`GET v2/studio/dashboard`	`analytics:read` and `earnings:read`
`GET v2/ProviderTransactions` · `list-payouts`	`earnings:read`
`GET v2/ProviderSubscriptions`	`subscribers:read`
`POST v2/studio/transfer-subscription` · `studio/cancel-subscription` · `studio/cancel-transfer` · `studio/grant-quota`	`subscribers:write`

Subscriptions and plan transfers are identified by opaque string ids (subscription.id, pending_transfer.id). Send them back exactly as you received them; they are not row numbers. studio/grant-quota takes the subscription.id that ProviderSubscriptions returns and an object_id from that subscription’s current_period.objects.

Worker code (edge gateway)

Route	Scope	What it does
`GET v2/provider-api-edge?slug=`	`code:read`	Mode, template, file list, handlers, variables, resources, settings
`GET v2/provider-api-edge-file?slug=&path=`	`code:read`	One stored file
`GET v2/provider-api-edge-source?slug=`	`code:read`	The files the Worker runs right now (generated or stored)
`GET v2/provider-api-edge-errors?slug=[&fingerprint=]`	`runtime-logs:read`	Runtime issues, or one issue with its recent occurrences
`GET v2/provider-api-edge-console?slug=[&request_id=]`	`runtime-logs:read`	Console output captured while logs are on
`GET v2/provider-api-edge-compute?slug=[&days=30]`	`analytics:read`	Cloudflare usage per metric, included allowance, list-price estimate
`GET v2/provider-api-edge-deployments?slug=`	`code:read`	Deployments, newest first: status, production / previous / latest, access, Keep active, URL; `pending` (see below)
`POST v2/update-api-edge-template` `{slug, template, production?, message?}`	`code:write`	Save the template (one route: origins, headers, query, switches, timeout, proxy) as a preview deployment
`POST v2/update-api-edge-files` `{slug, files: [{path, content}], delete: [path], production?, message?, git?, note?, redeploy?}`	`code:write`	Write and delete files (code mode) as a preview deployment; `git` records `{commit, branch, repository, pr}`; `redeploy: true` deploys unchanged files again
`POST v2/update-api-edge-mode` `{slug, mode: "code" \| "template", production?}`	`code:write`	Take the code over, or go back to the template, as a preview
`POST v2/discard-api-edge-changes` `{slug}`	`code:write`	Return the template, files, variables and bindings to what production runs; archives the previews made since
`POST v2/update-api-variable` · `delete-api-variable`	`variables:write`	Variables (`{slug, name, kind, value, production?}` / `{slug, name, production?}`) as a preview
`POST v2/update-api-edge-resource`	`resources:write`	Resources (`{slug, kind, binding, class_name?}`) as a preview; `{slug, kind: "shared", share_id, binding}` binds a resource shared with the API
`POST v2/delete-api-edge-resource` `{slug, binding}`	`resources:delete`	Remove a binding; the resource is deleted once no active deployment binds it
`GET v2/provider-api-edge-shares?slug=`	`code:read`	Shared resources: grants per resource, invitations and grants to the API
`POST v2/share-api-edge-resource` `{slug, binding, target_slug, target_binding?}`	`shares:write`	Share a resource with another API (yours: bound at once with `target_binding`; another account’s: an invitation)
`POST v2/accept-api-edge-share` · `decline-api-edge-share` · `revoke-api-edge-share` `{share_id}`	`shares:write`	Answer an invitation; revoke a grant
`POST v2/update-api-edge-settings` `{slug, logs}`	`runtime:write`	Console logging switch
`POST v2/promote-api-edge-deployment` `{slug, deployment, note?}`	`deployments:promote`	Serve a deployment in production; the note is the public release note
`POST v2/rollback-api-edge` `{slug, note?}`	`deployments:promote`	Back to the deployment production served before
`POST v2/deploy-api-edge-changes` `{slug, deployment?, note?}`	`deployments:promote`	Deploy the pending changes: promotes the latest preview (`deployment`: the id you checked; refused when newer changes were saved since) with an optional release note
`POST v2/update-api-edge-deployment` `{slug, deployment, access?, keep?, active?}`	`deployments:promote`	`access` owner / everyone, Keep active, archive (`active: false`) or activate

Every save is a preview unless it sends production: true, which also needs deployments:promote; note is the public release note of a production save. A save returns deploy: deployed with the new deployment (id, number, url) and whether it was promoted, or error with the build message. deploy.pending (also in provider-api-edge and provider-api-edge-deployments) lists what production does not run yet: changes ([{type: mode | template | file | variable | resource, name, change: added | changed | removed}]), production ({id, number}) and deployment, the latest preview ({id, number, status, error, url, current}; current: false means no deployment holds the saved changes yet). preview: true is still accepted and changes nothing. See Deployments and Worker code.

Your subscriptions

Route	Scope	What it does
`GET v1/subscriptions[?limit=&offset=]`	`subscriptions:read`	Your subscriptions
`GET v2/pending-transfers`	`subscriptions:read`	Plan transfers a provider offered you
`POST v2/subscribe-to-plan` `{plan_slug}`	`subscriptions:write`	Subscribe; a paid plan is paid as described above
`POST v2/subscription-pay-due` `{subscription_id}`	`subscriptions:write`	Pay a past-due subscription
`POST v2/UnsubscribeFromPlan` · `UnsubscribeFromPlanAtEnd` · `RevertCancellation` `{plan_slug}`	`subscriptions:write`	Cancel now, cancel at the end of the period, or undo that
`POST v2/subscription-auto-renew` `{subscription_id, active}`	`subscriptions:write`	Turn off automatic renewal when a quota runs out; turning it on is refused with `session_required` (its charges are outside the token’s spend limit)
`POST v2/accept-transfer` · `reject-transfer` `{transfer_id}`	`subscriptions:write`	Answer a plan transfer (accepting pays as above)

Projects and API keys

Route	Scope	What it does
`GET v2/projects`	`keys:read`	Your projects with their key counts
`POST v2/create-project` `{name}` · `rename-project` `{project, name}` · `delete-project` `{project}`	`keys:write`	Projects (`project` is the `proj_…` id)
`GET v1/api-keys[?reveal=true]`	`keys:read`	Your keys, values masked unless `reveal=true`
`POST v2/create-api-key` `{project?, label?, reveal?}`	`keys:write` (+ `keys:read` for the value)	A new key, in the default project without `project`; answers its `id`, `project` and the key (masked unless `reveal`)
`POST v2/set-api-key-label` `{api_key, label}` · `set-api-key-restrictions` `{api_key, restrict_all, api_slugs}` · `set-api-key-gateway-headers` `{api_key, hide_gateway_headers}`	`keys:write`	Label, API access, JoJ API headers; `api_key` is the key’s `id`
`POST v1/delete-api-key` `{api_key: {id}}`	`keys:write`	Delete a key; it stops working at once

Usage, billing, messages and activity

Route	Scope
`GET v2/dashboard`	`usage:read` and `subscriptions:read`
`GET v2/analytics-by-sub?subscription_id=[&project=&api_key=]` · `request-logs-by-sub?subscription_id=[&api_key=]`	`usage:read`
`GET v2/invoices` · `invoice-pdf?id=` · `billing-profile` · `payment-methods` · `POST v2/invoice-receipt`	`billing:read`
`GET v2/dm-conversations` · `dm-messages` · `dm-unread-count` · `dm-can-message`	`messages:read`
`POST v2/dm-send` `{recipient_username, content}`	`messages:write`
`GET v2/activity`	`activity:read`

The public catalog

POST v1/marketplace/search, GET v2/api-page, GET v2/UserPage, GET v2/landing-page, GET v2/sitemap-data and GET v2/billing-countries need no scope; any token with the current scopes can call them. api-page of one of your own APIs needs apis:read, since it shows hidden endpoints too.

Audit and limits

Every request made with a token is logged with its outcome — allowed, refused route, missing scope, refused resource — and kept for 90 days; the token’s last used stamp is in Settings › Tokens, and every change a token makes is recorded with the token that made it. A token can be valid for at most a year, an account can hold 20 live tokens, and the import routes share the Studio’s limit of 200 imports an hour. Keep tokens where your scripts read secrets from, never in a repository. If one leaks, revoke it in Settings › Tokens; the revocation is immediate.

Getting Started

API Studio

API Consumers

API Gateway

Account

Management tokens are not API keys

Create a token

Templates

Scopes

Your APIs

Your Workspace and account

Never on a token

Limit a token to some APIs or projects

Paying with a token

API keys and agents

Check a token

Calling it

Tokens created before these scopes

Routes

Listings

Imports — publishing an OpenAPI document

Pricing

Analytics, customers and earnings

Worker code (edge gateway)

Your subscriptions

Projects and API keys

Usage, billing, messages and activity

The public catalog

Audit and limits

​Management tokens are not API keys

​Create a token

​Templates

​Scopes

​Your APIs

​Your Workspace and account

​Never on a token

​Limit a token to some APIs or projects

​Paying with a token

​API keys and agents

​Check a token

​Calling it

​Tokens created before these scopes

​Routes

​Listings

​Imports — publishing an OpenAPI document

​Pricing

​Analytics, customers and earnings

​Worker code (edge gateway)

​Your subscriptions

​Projects and API keys

​Usage, billing, messages and activity

​The public catalog

​Audit and limits

Management tokens are not API keys

Create a token

Templates

Scopes

Your APIs

Your Workspace and account

Never on a token

Limit a token to some APIs or projects

Paying with a token

API keys and agents

Check a token

Calling it

Tokens created before these scopes

Routes

Listings

Imports — publishing an OpenAPI document

Pricing

Analytics, customers and earnings

Worker code (edge gateway)

Your subscriptions

Projects and API keys

Usage, billing, messages and activity

The public catalog

Audit and limits