Create portal session
Create a portal session for an end user and get the URL to redirect them to.
The URL carries a single-use exchange code valid for 15 minutes, which the portal
redeems exactly once for a 24-hour access token via portal.exchangeCode.
Required Permissions
Authorization runs in two stages, and both must pass.
First, your root key must have one of the following permissions:
portal.*.create_portal_session(to mint sessions for any portal in the workspace)portal.<portal_id>.create_portal_session(to mint sessions for a specific portal)
Second, a session can never carry a capability your root key does not itself hold. Each requested scope additionally requires the equivalent permission on every keyspace the portal resolves to:
keys:readrequiresapi.<api_id>.read_keyandapi.<api_id>.read_apikeys:rerollrequiresapi.<api_id>.create_key, plusapi.<api_id>.encrypt_keywhen the keyspace stores encrypted keysanalytics:readrequiresapi.<api_id>.read_analytics
The * form of each is also accepted. Requesting a scope you do not hold
returns 403 for the whole request rather than minting a reduced session, so a
missing grant is visible instead of surfacing later as a broken portal.
Missing the portal permission itself returns 404, not 403: a caller who cannot mint for a portal is not told whether it exists.
Your root key must also be associated with a workspace that has an enabled portal.
Authorizations
Unkey uses bearer tokens for authentication. Public integrations use root keys, while the dashboard proxy uses short-lived JWTs. To authenticate, include the token in the Authorization header of each request:
Root keys have specific permissions attached to them, controlling what operations they can perform. Legacy permissions use tuple strings like api.*.create_key; resource permissions use Unkey Resource Names plus actions, like unkey:v1:ws_123:keyspaces/*#create_key.
Security best practices:
- Keep root keys secure and never expose them in client-side code
- Use different root keys for different environments
- Rotate keys periodically, especially after team member departures
- Create keys with minimal necessary permissions following least privilege principle
- Monitor key usage with audit logs.
Body
Identifies a resource by either its unique ID or its slug. Accepts a prefixed ID (such as 'proj_' or 'app_') or a slug.
3 - 255^[a-zA-Z0-9_-]+$"proj_1234abcd"
The end user's identifier in the customer's system. Accepts arbitrary string values (user IDs, emails, UUIDs, etc.).
1 - 256"user_123"
The capabilities granted to the end user in the Portal, from a fixed
vocabulary. All capabilities are scoped to this end user: key capabilities
(keys:*) apply only to keys the end user owns within the keyspace
configured on the portal. An end user can never see another identity's
keys.
Rerolling and usage analytics are both reached from the keys page, so
keys:reroll and analytics:read each require keys:read in the same
session; requesting either without it is rejected.
Each scope requires the equivalent permission on your own root key. See Required Permissions on this operation.
1keys:read, keys:reroll, analytics:read Absolute URL the end user is sent back to when they leave the portal, or when their session expires mid-visit. Set per session rather than per portal, so one portal can serve several entry points and return each user to the page they came from.
When omitted, the portal shows no return link.
500"https://app.example.com/settings/api-keys"
Response
Session created successfully. Redirect the end user to the returned URL.