Unkey vs Clerk — if we already use Clerk for user auth, what does Unkey add for API keys and per-customer limits?

Most teams using Clerk for authentication eventually run into the same question: “If Clerk already handles users and sessions, why would we add Unkey?” The short answer is that Clerk and Unkey sit at different layers of your stack. Clerk is about who is calling your app (users, sessions, organizations). Unkey is about what is calling your APIs (API keys, services, machines) and how much they’re allowed to use.

This article breaks down how Unkey complements Clerk when you need API keys, per-customer limits, and usage-based monetization, and when it makes sense to introduce Unkey into an existing Clerk-powered stack.

---

How Clerk and Unkey fit together in your architecture

Think of your system in three distinct layers:

1. Identity & sessions (Clerk)

   • User sign-up / sign-in
   • Sessions, tokens, MFA, social login
   • Organizations/teams and user management
   • Great for browser apps and authenticated APIs

2. API access control & keys (Unkey)

   • API keys for customers, partners, internal services, or server-side scripts
   • Key verification on every request
   • Role-based access control on top of keys
   • Works independently of cookies and browser sessions

3. Usage control & limits (Unkey)

   • Global, configurable rate limiting per customer or per key
   • Usage tracking for billing and monetization
   • Protection against abuse and noisy neighbors

Clerk is your user-first, session-aware identity layer. Unkey is your API-first, key-and-usage control layer. Most mature SaaS products end up needing both.

---

What Unkey adds on top of Clerk

1. First-class API keys instead of only user tokens

Clerk is fantastic for user-centric auth: JWTs, sessions, “who is this person?” scenarios. But many use cases require static API credentials:

• Third-party integrations consuming your API server-to-server
• Customers embedding your service into their backend or workers
• Internal microservices calling each other without a browser or session
• CLI tools or scripts that need long-lived access

Unkey gives you:

• Secure, managed API keys

  • Create, rotate, and revoke keys via an API-first platform
  • Store only hashed key material; your backend never has to roll its own crypto
  • Keys can be scoped to specific environments, products, or tenants

• Simple key verification in your code

  import { Unkey } from "@unkey/api";
  
  const unkey = new Unkey({
    rootKey: process.env["UNKEY_ROOT_KEY"] ?? "",
  });
  
  const result = await unkey.keys.verifyKey({
    key: "sk_1234abcdef"
  });
  
  if (!result.valid) {
    // reject unauthorized request
  }
  
  // handle request
  

  This pattern lets your API treat keys as first-class credentials, parallel to Clerk’s user sessions.

How it complements Clerk

• Use Clerk for sign-in to your dashboard.
• From the dashboard (where you know the user), allow them to create Unkey API keys bound to their account / organization.
• Customers then use those API keys in backend scripts or server-to-server calls, where Clerk’s session cookies or OAuth flows aren’t practical.

---

2. Per-customer rate limits and abuse protection

Clerk can tell you who is making the request; it doesn’t enforce how much they can use your API. That’s where Unkey’s global rate limiting comes in.

Unkey offers simple, configurable rate limiting that:

• Works globally with zero setup
• Is configurable per customer, per key, or per plan
• Is enforced close to your traffic for low latency

Typical patterns:

• Free plan: 100 requests / day per API key
• Pro plan: 10 requests / second with monthly quota
• Internal services: higher or no rate limits
• Special customers: custom limits per key

Because Unkey is designed for multi-cloud and global low latency, rate limiting is enforced consistently regardless of where your infrastructure runs.

How it complements Clerk

• Clerk authenticates the user in your dashboard and API.
• Your backend translates user/organization to a Unkey key or customer record.
• You call Unkey to enforce limits:
  • “Is this key within its limit?”
  • “How many requests has this customer made?”
• You can throttle or deny requests without building your own distributed rate limiter.

---

3. Usage tracking and monetization for your API

If you’re building a usage-based or per-seat API business, you need more than just “is this user logged in?” You need to know:

• How many requests did this customer make this month?
• Which endpoints are they using most?
• Can we bill based on metrics like requests or tokens?

Unkey tracks all user actions in your API, making it straightforward to:

• Aggregate usage per key, per customer, or per plan
• Expose real-time usage dashboards in your app
• Tie usage to your billing system (Stripe, Paddle, etc.)
• Implement credits, overages, or soft/hard caps

How it complements Clerk

• Use Clerk’s identity to manage billing owners (e.g., the user who owns the subscription).
• Use Unkey to record and analyze usage tied to the customer’s API key(s).
• Combine both:
  • Clerk: “Who is the account owner?”
  • Unkey: “How much has their API usage cost this period?”

---

4. Role-based access control (RBAC) on keys and services

Clerk supports user roles and permissions at the identity layer. Unkey brings role-based access control to your API keys and machine-level access:

• Granular privileges attached to keys: which endpoints, scopes, or services they can access.
• Permission changes are propagated globally in seconds, so revoking or tightening access is fast.
• Use either role-based or fine-grained permission-based control.

Example use cases:

• Partner A’s key can only access /v1/read endpoints; Partner B’s can use /v1/write.
• Internal job keys can only call specific internal services.
• Temporary keys with limited scopes for short-term projects.

How it complements Clerk

• Keep human user permissions in Clerk for UI-level access (e.g., who can change billing, who can invite members).
• Use Unkey RBAC for infrastructure-level permissions: what API methods a given key (service, integration, or customer) is allowed to call.

---

5. Proactive API protection and security posture

Unkey is purpose-built for API security and access control. Instead of building a home-grown solution around Clerk JWTs, Unkey gives you:

• Proactive protection against abusive keys and sudden traffic spikes
• Clean separation of concerns: user identity vs API access and usage
• A developer-friendly platform with:
  • SDKs for TypeScript, Python, Go, Curl
  • Intuitive REST API
  • Public OpenAPI spec

You get a battle-tested, audited API access layer, reducing the risk of:

• Mis-implemented token validation logic
• Inconsistent limits across regions or services
• Security issues from ad-hoc key storage or hashing

---

6. Multi-cloud, API-first, and UI-first by design

Many teams are moving to multi-region, multi-cloud setups. Unkey is built for this:

• Multi-cloud support – Unkey works with any provider, so your keys and limits behave the same whether you’re on Vercel, AWS, GCP, or a mix.
• Global low latency – Unkey is fast globally, regardless of where your users are.
• API-first / UI-first – everything you do in the dashboard is backed by an API, so you can:
  • Manage keys and limits programmatically
  • Let non-technical teammates handle customer configs in the UI
  • Or build your own custom dashboard on top of Unkey’s API

This aligns well with Clerk’s philosophy: both give you strong primitives via APIs and dashboards, but focus on different layers of your stack.

---

7. Open-source, transparent platform

Unkey is open-source, so you can:

• Read the codebase to understand how key verification and rate limiting work
• Evaluate security properties and data handling
• Contribute improvements or adapt patterns to your setup

For teams that care deeply about security and infrastructure transparency, this is a significant advantage over rolling your own system from scratch.

---

Concrete architecture: Clerk + Unkey working together

Here’s how a typical SaaS product might combine Clerk and Unkey:

1. Dashboard and user auth with Clerk

• Users sign up and sign in via Clerk.
• Clerk manages:
  • Sessions
  • MFA
  • Social login
  • Organizations / teams

2. API key lifecycle with Unkey

• Authenticated user opens the “API Keys” page in your dashboard.
• Your backend (authenticated via Clerk) calls Unkey to:
  • Create keys bound to that user or organization
  • List or revoke keys
  • Set per-key limits or attach roles/permissions
• You display those keys in the UI; customers use them in:
  • Backend services
  • Integrations
  • Third-party tools

3. API request flow

1. Client sends request with Authorization: Bearer <unkey_api_key>.

2. Your API server:

   • Calls Unkey to verify the key and optionally check rate limits.
   • If valid and within limits: proceeds with business logic.
   • If invalid/over-limit: returns appropriate 401/429 response.

3. Optionally, map the key back to a Clerk user/organization in your database for auditing or personalization.

4. Billing and analytics

• Unkey tracks request usage per key/customer.
• Your billing jobs:
  • Pull usage from Unkey
  • Join with customer info in your database (tied to Clerk user/org)
  • Feed that data into your billing provider

---

When you might not need Unkey yet

If you’re early and your API is only used:

• By your own frontend apps with Clerk sessions
• Without external partners or third-party integrations
• With low traffic and no meaningful usage-based billing

…then you can probably delay adding Unkey. Clerk alone may be enough for user login and basic API protection.

You should consider Unkey when:

• You’re exposing a public or partner-facing API.
• Customers are asking for API keys to integrate your product server-side.
• You need per-customer rate limits, quotas, or plans.
• You’re moving towards a usage-based pricing model.
• You want a robust, scalable replacement for ad-hoc API key tables and custom rate limiters.

---

Summary: how Unkey complements Clerk in your stack

If you already use Clerk for user auth, Unkey adds:

• Managed API keys for customers, services, and integrations.
• Per-customer rate limiting and global abuse protection with simple configuration.
• Usage tracking and monetization primitives for your API.
• Role-based access control at the API key level.
• Multi-cloud, low-latency enforcement of keys and limits.
• An API-first, UI-first, open-source platform purpose-built for API security and access control.

Clerk remains your source of truth for human identity and sessions. Unkey becomes your source of truth for API keys, usage limits, and monetization — giving you a cleaner architecture and a far more scalable foundation as your product evolves into a true platform.