What it is: Unkey is an open-source developer platform for modern APIs whose core job is API key management — issuing, verifying, and revoking keys — with rate limiting, per-key permissions, usage analytics, and audit logs bundled in. It's the plumbing that turns "we should really put auth in front of this API" into an afternoon instead of a sprint.

Every API that leaves the prototype stage hits the same wall. You need to hand callers a key, check it on every request, stop one customer from hammering you into the ground, give different keys different powers, and see who's using what. None of that is your product. All of it is load-bearing, security-sensitive, and annoying to get right. Unkey's bet is the same one Resend makes for email and OpenRouter makes for model access: infrastructure you'd rather not build should collapse into one clean call.

Who it's for#

Founders and builders shipping an API that other people (or other agents) call with a key. That includes:

If you write the API and think of keys as something you verify, not a control plane you want to operate, this is aimed at you.

Getting started#

The mental model is a single loop: your API receives a request, you hand the caller's key to Unkey, Unkey tells you if it's valid and what it's allowed to do, you allow or reject. You never store or compare raw keys yourself.

With the official SDK, verification on each request looks like this:

import { Unkey } from "@unkey/api";

const unkey = new Unkey({ rootKey: process.env.UNKEY_ROOT_KEY });

// on every incoming request to your API:
const { result, error } = await unkey.keys.verifyKey({
  key: requestApiKey, // the key the caller sent you
});

if (error || !result.valid) {
  return new Response("Unauthorized", { status: 401 });
}

// result also carries ownerId, permissions, and remaining
// rate-limit / usage quota — gate your handler on those.

Issuing a key (say, when a customer signs up or buys a plan) is the mirror image — a keys.createKey call where you attach an owner, permissions, an optional expiry, and a rate limit, and get back the key to show the customer once. Because the method names and exact routes evolve as the platform grows toward gateway and deployment features, pull the current signatures from unkey.com/docs before you wire it in. The shape above — verify in, valid + metadata out — is the part that doesn't change.

Pricing#

Unkey follows the standard developer-tool model: a free tier to build and launch on, then usage-based paid plans that scale with your verification and rate-limit volume. Because it's open source under AGPL, self-hosting is free — you run the control plane yourself and pay nobody, at the cost of operating it. Exact tier limits move around, so confirm the current numbers at unkey.com/pricing before you build a budget around them.

The catch / where it fits#

Two honest limits.

First, it's source-available, not community-developed. Unkey is licensed AGPL and is open enough that you can read it, self-host it, and avoid lock-in — but the team is not currently accepting external pull requests while it focuses on platform stability. Treat it as open-to-run, not open-to-co-develop; if you were hoping to upstream your own fixes, that door is shut for now.

Second, verification sits in your request path. Every protected call makes a check against Unkey, which is mitigated by verifying from globally distributed infrastructure but is still a network hop and an external dependency. For most APIs that trade is obviously worth it; if you have ultra-low-latency requirements or need to survive Unkey being unreachable, plan for caching valid results briefly and a sensible fail-open/fail-closed policy.

Where it fits: you're shipping an API — for humans or for agents — keys and rate limits are table stakes you need done well, and you'd rather integrate a purpose-built platform than either hand-roll auth or stand up a full enterprise gateway like Kong. That's the sweet spot. If you need deep request transformation, protocol mediation, and a plugin ecosystem, that's gateway territory and a heavier tool is the right call.