Delete portal
Delete a portal and revoke the sessions it minted.
Unreleased and subject to change without notice.
Its end users lose access rather than keeping it until their tokens expire. Revocation is not instantaneous: session lookups are cached briefly, so a request already in flight may still succeed.
The app or keyspace it served is untouched, and its slug becomes free for a new portal.
Required Permissions
Your root key must have one of:
portal.*.delete_portal(to delete any portal in the workspace)portal.<portal_id>.delete_portal(to delete a specific portal)
Without the permission this returns 404, not 403.
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"
Response
Portal deleted and its sessions revoked.
Metadata object included in every API response. This provides context about the request and is essential for debugging, audit trails, and support inquiries. The requestId is particularly important when troubleshooting issues with the Unkey support team.
Empty response object by design. A successful response indicates this operation was successfully executed.