Skip to main content
The developer portal is a hosted page where your users see their API keys, roll them over, and check their usage, without you building any of it. You keep the sign-in: your backend creates a short-lived session for a user who’s already signed in, and redirects them to the portal. Each user only sees their own keys.
The developer portal is in beta.You can manage a portal for a keyspace in the dashboard, with the API, or with the CLI (create-portal, get-portal, update-portal, delete-portal, create-session). A portal for a deployed app can only be managed with the API or the CLI for now.

​
What a portal is bound to

A portal shows keys from one place. Set keyspaceId to show the keys in a keyspace. Or set appId to a Compute to show keys from every keyspace the gateway accepts for that app. Send one or the other, not both. You can change it later. A user only sees keys whose identity externalId matches the one in their session. Keys without an identity never show up in the portal, so attach identities to keys you want users to manage.

​
Fields

​
string
required
A handle for the portal in API calls, unique in your workspace. 3 to 64 lowercase letters, digits, and hyphens, not starting or ending with a hyphen. Your users never see it. You can use the slug or the pc_ ID wherever you name a portal. A taken slug, or a second portal for the same keyspace or app, fails with HTTP 409 err:unkey:data:portal_already_exists.
​
string
required
1 to 64 characters shown in the portal header and page titles. Change it any time.
​
string
The keyspace to serve. Mutually exclusive with appId.
​
string
The app to serve. Mutually exclusive with keyspaceId.
​
boolean
default:"true"
Whether new sessions can be created. Disabling also ends sessions that are already live.
​
string
https:// URL of the logo in the portal header, up to 500 characters. Your users’ browsers load it directly, so that host sees their IP address. Set null on update to remove it.
​
string
Six-digit hex color (#6366f1) for buttons and accents. Set null on update to go back to the default.
When you read a portal, logoUrl and primaryColor come back under branding, and createdAt and updatedAt are Unix milliseconds.

​
Create a portal

You need a root key with the permissions listed on this page. Create one under Root Keys in the dashboard sidebar. See Permission reference for every permission.
Creating a portal needs portal.*.create_portal. Reading, updating, and deleting need read_portal, update_portal, or delete_portal, either as portal.*.<action> or scoped to one portal as portal.<portalId>.<action>. Creating sessions needs a separate permission, covered on Portal sessions.
You get the portal back with its pc_ ID. Next, create a session for a signed-in user and redirect them to the URL you get back.

​
Change or remove a portal

portal.updatePortal takes the same fields, all optional. Leave a field out to keep it. Pointing the portal at a different keyspace or app, or disabling it, ends every live session. portal.deletePortal deletes the portal, ends all its live sessions, and frees the slug. Both write an audit log entry (portal.update or portal.delete).

​
Next steps

Portal sessions

Create a session for a signed-in user, redirect them to the portal, and set the permissions your root key needs.

What portal users can do

The keys and analytics tabs, what each scope unlocks, and the endpoints behind them.
Last modified on October 14, 2026