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 (portals create, portals get, portals update, portals delete, portals sessions create). 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 prt_ 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

Create a root key with the permissions listed on this page under Root Keys in the dashboard sidebar. CLI commands can instead use a session from unkey login with the required permissions. See Permission reference for every permission.
Creating a portal needs unkey:v1:<workspace_id>:projects/<project_id>/portals/*#write for the project that owns the app or keyspace. You also need read permission on that resource: unkey:v1:<workspace_id>:projects/<project_id>/apps/<app_id>#read for an app or unkey:v1:<workspace_id>:projects/<project_id>/keyspaces/<keyspace_id>#read for a keyspace. Broader grants that cover these resources and actions also authorize the request. Reading and deleting need read_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 prt_ 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. Updating requires write permission on unkey:v1:<workspace_id>:projects/<project_id>/portals/<portal_id>, or a broader grant such as unkey:v1:<workspace_id>:**#write. Changing the mapped resource also requires read permission on the target app or keyspace. See portals update for the target URNs and error behavior. portal.deletePortal deletes the portal, ends all its live sessions, removes its custom domains, 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.

Custom domains

Serve the portal from a hostname you own, with DNS records, verification, and a certificate.
Last modified on November 12, 2026