Personal Access Tokens
Scoped, revocable developer tokens for the Simple Telecom platform: the secret is shown exactly once, rotation is atomic, revocation is instant, and only the account owner can manage them. Coming soon.
Frequently Asked Questions
What is a personal access token?
A PAT is a long-lived developer token that authenticates your integrations against the Simple Telecom platform — the MCP server and the v1 platform API. You choose its scopes and expiry, and you can rotate or revoke it at any time.
Can I see my token again after creating it?
No — and that is deliberate. The secret is displayed exactly once at creation and stored only as a hash, so nobody can recover it afterwards. If you lose it, rotate: a new token is issued and the old one is revoked atomically.
Who can create and manage tokens?
Only the account owner. Operators and viewers cannot create, rotate or revoke tokens — the platform refuses the request regardless of what the integration tries.
What happens when I revoke a token?
It stops working immediately. Any queued calls running under that token are stopped as well — revocation is not just "no new requests".
How long can a token live?
Expiries are capped — you cannot create a token that never expires or lives unreasonably long. Exact caps are confirmed at launch on the changelog page.
How is this different from my current API token?
Today you generate a Bearer token in the console settings — that keeps working and is covered in API authentication. PATs are the platform-era model: scoped, capped, atomically rotatable, with full lifecycle control in the console.
Status: coming soon. Personal access tokens ship with the platform integrations release (MCP server, scoped access). This page documents the designed lifecycle from the product specification. Your current console tokens keep working unchanged — see API authentication. The changelog announces the launch.
What a personal access token is
A PAT is the credential your integrations use against the Simple Telecom platform: a long-lived, scoped token that authenticates the MCP server or the platform v1 API. Unlike a session, it belongs to a project rather than a login; unlike an API key, it has a managed lifecycle you control from the console — create, inspect, rotate, revoke.
Every token carries exactly the scopes you granted it, and nothing else.
The lifecycle
Create — the secret is shown exactly once
When you create a token you give it a label, its scopes and an expiry. The console shows the full secret once, at creation. We store only a hash — after you leave that screen, nobody can retrieve the secret, including us. Copy it into your integration immediately.
Unknown or dangerous scope names are refused at creation — a typo cannot silently mint an over-privileged token, and scopes like payments or cancellation do not exist to grant.
List — metadata only
The console lists your tokens: label, scopes, created date, expiry, last used. The secret is never shown in the list, in exports, in logs or in backups — anywhere.
Rotate — atomic, no overlap window
Rotation issues the new token and revokes the old one in a single atomic step: the old token stops working at the same moment the new one is valid. There is no window where both work, so a leaked credential can be cut over cleanly and immediately. Point your integration at the new secret and you are done.
Revoke — immediate, queued calls stop
Revoking a token stops it working instantly — and stops queued calls already running under it. Disabling a team member's account or disabling a service also stops tokens in flight; the platform does not let a revoked identity keep acting through an outstanding credential.
Expire — capped, by design
Tokens have a maximum lifetime; a request to create one that lives too long is refused. If your integration needs continuous access, rotation is the intended rhythm — and rotation is cheap because it is atomic.
Hygiene rules that keep you safe
- Never put a token in a URL — not in query strings, not in config exports.
- Never log it — the platform keeps secrets out of logs and metadata; match that on your side.
- Do not route tokens through third-party hosted key proxies. The token is the key to your account; keep it in your own client's configuration.
- Screenshot discipline — the create screen is the one chance; a screenshot of it is a leaked credential. Rotate if one ever escapes.
- Scope narrowly — a read-only token cannot be pushed to do more than read, no matter how it is used.
Where tokens fit
- MCP server — connect AI assistants, scoped by the same model.
- Scopes and permissions — what each scope allows and what is impossible by design.
- API authentication — today's Bearer tokens for the current REST API.
Part of the Simple Telecom API.