API tokens

An API token lets a program do what you do in the portal — create customers, issue licenses, suspend them, pull statements. If you provision panels from a marketplace, a control panel, or your own billing system, this is how you connect it. You manage tokens on the API Tokens page in Partner Center.

The token is the credential. Anyone holding it can act as your partner account, up to its scope, with no password and no second factor. Treat it exactly as you'd treat a password for the account.

Who can manage tokens

Billing and read-only users don't get a read-only view of the token list — they get no access, and see this instead:

Only partner owners and members can manage API tokens.

That is deliberate, not an oversight. Everywhere else in Partner Center, billing and read-only can see what they cannot change. Tokens are the exception because a token can itself issue licenses, so seeing the list is already more privilege than an auditor or a finance user is meant to carry. The usual "read is harmless" reasoning doesn't hold for credentials.

Creating a token

Go to API Tokens and click New token. Two fields:

• Label — what this token is for: marketplace-provisioning, billing-sync, staging. You'll be choosing which token to revoke months from now, and the label is all you'll have to go on. A token labelled test that nobody dares revoke is a permanent hole.
• Scope — Read-only or Read & write.

Choosing a scope

Pick read-only whenever the integration only reports — a billing reconciliation job, a dashboard, a usage export. Reach for read & write only when something genuinely provisions.

Worth knowing before you mint a write token: read & write includes managing tokens. A write token can mint further tokens and revoke existing ones, including itself. There's no narrower "can issue licenses but not manage credentials" scope, so a write token leaking is not just a provisioning problem — treat the blast radius as the whole account.

The token is shown once

When the token is created, the full secret is displayed a single time, with a Copy button:

This is the only time this token will be shown. Copy it now — it cannot be retrieved again.

That is literal. We store only a hash, so nobody — including us — can show you the secret again. Put it straight into wherever it belongs (your secrets manager, your CI configuration, your provisioning script's environment) before you close the dialog. If you lose it, revoke that token and mint a new one; there is no recovery step and no support ticket that retrieves it.

Tokens start with pcp_, which makes them easy to spot in a config file or a log — and easy for a secret scanner to catch if one ever lands in a repository.

After the dialog closes, the table shows only a short Token prefix, plus the Label, Scope, Created, Last used, and Status. Last used is the column to check when you're deciding whether a token is still needed: one that has never been used, or hasn't been used in months, is a credential you're carrying for nothing.

Revoking a token

Click Revoke on the row and confirm:

Revoke …? Any integration using this token will stop working immediately.

There's no grace period and no warning to the integration — the next request it makes fails. Before revoking, know what's using it. When rotating, mint the new token, deploy it, confirm the integration works on it, and then revoke the old one; that way the gap is zero.

A revoked token shows as Revoked and stays in the table rather than disappearing, so the record of what existed and when it stopped remains auditable.

Revoke immediately, without waiting to plan, when a token has appeared anywhere it shouldn't be — a commit, a log, a chat message, a screenshot, a support ticket — or when someone with access to it leaves. Rotation is cheap. A live credential in a place you didn't choose is not.

Using the token

Send it as a bearer token on the Partner API:

Authorization: Bearer pcp_your_token_here

Authenticated requests are rate-limited per token. Responses that reach that limiter include X-RateLimit-Limit (the burst capacity) and X-RateLimit-Remaining; a 429 supplies Retry-After. Authentication failures can occur before those per-token headers are set. Give each integration its own token instead of sharing one: separate tokens can be revoked independently, are rate-limited independently, and tell you from the Last used column which system is actually still running.

Full endpoint reference, request shapes, and error codes: Partner API.

Troubleshooting