Skip to main content
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.
Create a portal session so one of your end users can sign in to the portal. Redirect them to data.url. It works once and expires after 15 minutes. After they sign in, their session lasts 24 hours. The scopes you pass decide what they can do. data.id identifies the session. It isn’t a credential, so it’s safe to log. A disabled portal returns 403 “Portal is disabled”. A portal that doesn’t exist, or that your root key can’t reach, returns 404. Calls POST /v2/portal.createSession. See Portal sessions.

Usage

Flags

string
required
The end user’s ID in your system. The session only sees that identity’s keys.
string
required
Portal id or slug.
string[]
required
Comma-separated capabilities from keys:read, keys:reroll, and analytics:read. keys:reroll and analytics:read each need keys:read too, because both are reached from the keys page. The command rejects them without it.
boolean
default:"false"
Create a preview session for testing the portal without a real end user.
string
Full https:// URL the portal sends the user back to when they’re done, up to 500 characters. An http:// URL, a //host/path, or a bare path fails with 400.

Shared flags

Every resource command takes these. See CLI output and shared flags.
string
Root key used for the request. Falls back to UNKEY_ROOT_KEY, then stored credentials, including a CLI session. See CLI authentication for the full precedence order.
string
default:"https://api.unkey.com"
Base URL of the API. Falls back to UNKEY_API_BASE_URL. You don’t normally need to set it.
string
default:"~/.unkey/config.toml"
Path of the TOML config file. Falls back to UNKEY_CONFIG. An explicit --config takes precedence over a stored CLI session. Browser login stores a session, not a root key in this file. See CLI authentication.
enum
default:"human"
Use human (default) for name-first summary tables and single-response trees, or json for the unchanged full response envelope, including all fields and pagination. Trees wrap long values without truncation. Terminal tables use relative timestamps and may shorten display names and descriptions, but never identifiers, slugs, or credentials. Redirected human output keeps complete values and uses RFC3339 UTC timestamps. Falls back to UNKEY_OUTPUT; other values are rejected. --json also selects JSON output. Add --debug to print the request ID to stderr. See Output formats.
boolean
Print the successful response’s request ID to stderr, separate from stdout.
boolean
Print the full response as JSON. Takes precedence over a valid --output or UNKEY_OUTPUT value.
string
Send this JSON as the whole request body instead of using the command’s flags. You can’t combine it with them.

Required permissions

Your root key needs unkey:v1:<workspace_id>:projects/<project_id>/portals/<portal_id>/sessions/*#write. Write permission on the portal itself does not grant permission to mint sessions. You also need the following grants on every keyspace behind the portal. Each resource below has the prefix unkey:v1:<workspace_id>:projects/<project_id>/keyspaces/<keyspace_id>:
  • keys:read needs /keys/*#read and #read.
  • keys:reroll needs /keys/*#write, including for recoverable keys.
  • analytics:read needs /logs#read.
Broader URN grants that cover these resources and actions are also accepted. A grant on one concrete key cannot satisfy the keys/* requirement. Without the session permission, you get a 404 as if the portal didn’t exist, or a 403 that names the missing permission if your key can read the portal or its sessions. With it but missing a scope’s permission, the whole request fails with 403. Unkey never creates a session with fewer scopes than you asked for. See Root key permissions.

Examples

Read and reroll keys
Analytics with a return URL
Or send the whole request as JSON:
Raw body
Last modified on November 12, 2026