Skip to main content
Multi-tenant applications serve multiple customers (tenants) from a single codebase. Unkey’s identities feature makes it easy to manage API keys, enforce shared limits, and scope permissions per tenant — whether your tenants are individual users, teams, or entire organizations.

What are identities?

Identities connect multiple API keys to a single entity. Think of them as a grouping mechanism:

Without identities

Each API key is isolated. A user with 3 keys has 3 separate rate limits and configurations.

With identities

Group all keys under one identity. Share rate limits, metadata, and permissions across all keys for that tenant.

Why use identities for multi-tenant apps?

Architecture patterns

User-based tenancy

Each user gets their own identity:

Organization-based tenancy

Entire organizations share a single identity:

Hybrid tenancy

Users have individual keys, but organizations have shared resources:

Shared rate limits

Enforce rate limits across all keys for a tenant:
Key-level rate limits still apply. If a key has its own rate limit, both the key limit and identity limit are enforced. The stricter limit wins.

Shared metadata

Store tenant configuration on the identity:

Permission scoping

Combine identities with RBAC for tenant-scoped permissions:

Usage tracking per tenant

Aggregate analytics by identity:

Plan upgrades and downgrades

Update identity when tenants change plans:

Multi-environment support

Manage separate environments per tenant:

Best practices

Always use your own user/org IDs as the externalId. This makes it easy to look up identities and keeps your systems in sync.
Put shared configuration on the identity, not individual keys. Only store key-specific data (like environment or name) on the key itself.
For true multi-tenancy, set rate limits and quotas on the identity. This prevents users from bypassing limits by creating multiple keys.
Use identities to isolate data. In your application, always filter queries by the identity’s externalId to prevent cross-tenant data leaks.

Real-world example: SaaS platform

Complete implementation for a multi-tenant SaaS:
1

Create organization

2

Add team members

3

Verify with tenant isolation

4

Handle upgrades

Next steps

Authorization with RBAC

Add role-based permissions to your multi-tenant app

Rate limit overrides

Customize rate limits per tenant tier