# Build vs. Buy

The rest of this guide covers every component of a production API key system, from [generation](/docs/implementation/key-generation) and [hashing](/docs/security/hashing-and-storage) through [rotation](/docs/security/key-rotation), [leak detection](/docs/security/leak-detection), and [management at scale](/docs/operations/key-management-at-scale). Each page is practical and implementation-focused, because understanding how these systems work is valuable regardless of whether you build them yourself.

But before you start writing code, ask the question: should you build this at all?

## The Real Scope of a Key System

It is tempting to think of API key auth as a single feature. In practice, a production-grade system includes at least these components:

- **Key generation** with cryptographic randomness and a [well-designed format](/docs/implementation/key-formats-and-prefixes)
- **Hashed storage** with indexed lookups and a fast caching layer
- **Validation middleware** that runs on every request with [timing-safe comparison](/docs/implementation/validation-and-lookup)
- **[Scope enforcement](/docs/security/scoping-and-permissions)** to restrict what each key can do
- **Rate limiting** per key, likely with tiered plans
- **Rotation support** with [overlapping key validity](/docs/security/key-rotation) and grace periods
- **Revocation** with propagation across all nodes within seconds
- **Expiration policies** with [automated warnings](/docs/security/expiration-policies)
- **Leak detection** integration with GitHub secret scanning or similar tools
- **Audit logging** for every auth event and key lifecycle change
- **A management interface** for creating, viewing, rotating, and revoking keys

Each of these is individually straightforward. Together, they form a distributed system with its own caching, replication, monitoring, and incident-response requirements. The ongoing cost is not just building it; it is operating and maintaining it.

## When Building Your Own Makes Sense

Building in-house is the right call when you have specific requirements that off-the-shelf solutions cannot meet, or when the cost of a managed solution does not justify the value.

**You need custom key semantics.** If your key system has unusual requirements (composite keys that encode routing information, keys that map to complex multi-tenant hierarchies, or keys that integrate with a proprietary identity system), a managed solution may not be flexible enough. Custom key formats with embedded metadata are hard to retrofit into a platform that has its own key structure.

**You have regulatory or data-residency constraints.** Some industries and regions require that authentication data never leave specific jurisdictions or infrastructure boundaries. Self-hosted solutions offer this control; managed platforms may or may not, depending on the provider.

**You already have the infrastructure.** If you are already running a reverse proxy, a caching layer, a secrets manager, and a monitoring stack, the marginal cost of adding key auth on top of that infrastructure is lower. You are not building from scratch; you are adding a feature to an existing platform.

**Your scale makes per-request pricing prohibitive.** Managed API gateways typically charge based on request volume. If your API handles billions of requests per month, the managed-service cost may exceed the engineering cost of a self-built solution. Estimate the fully-loaded cost of an engineer-month against the projected platform bill at your anticipated request volume.

**You want full ownership of the auth path.** Some teams, particularly in security-sensitive domains, want to audit every line of code in the authentication pipeline. A managed solution is a black box by comparison. If your threat model requires deep inspection of the auth path, building your own gives you that visibility.

## When Buying Makes Sense

Adopting a managed solution (whether a [full API gateway](/docs/architecture/gateway-based-authentication), a dedicated API key management platform, or a cloud provider's auth service) makes sense when the operational cost of building outweighs the licensing cost. Platforms like [Zuplo](https://zuplo.com/docs/articles/api-key-management?ref=apikeys-guide&utm_source=apikeys-guide&utm_medium=web&utm_campaign=api-keys) bundle many of the components listed above (key generation, hashed storage, validation, rate limiting, rotation, revocation, leak detection, and a developer portal) into a single managed service.

**Your core product is not an API platform.** If your team builds a SaaS product, a mobile backend, or an internal tool, the API key system is infrastructure supporting your product, not the product itself. Time spent building and maintaining key auth is time not spent on features your customers pay for.

**You have a small platform team (or none).** A production key system requires ongoing maintenance: patching the caching layer, responding to revocation-propagation bugs, updating leak-detection integrations, rotating the infrastructure's own credentials. If you do not have a dedicated platform team, that maintenance falls on product engineers who have other priorities.

**You need to move fast.** A managed solution can have API key auth working in hours or days. A custom build, done well, takes weeks to months, and longer if it includes a management UI, rotation workflows, and leak detection. If time-to-market matters more than full control, buying is the faster path.

**You want fewer components to get right on the first pass.** Hashed storage, timing-safe comparison, revocation propagation, graduated rate limiting: these are each well-documented in this guide, but implementing them all correctly in one go is non-trivial. A managed solution that already handles them means fewer moving parts for your team to build and test.

**You plan to monetize your API.** If you need usage metering, plan-based rate limits, and billing integration, a managed API platform typically includes these — [Zuplo](https://zuplo.com/docs/articles/monetization?ref=apikeys-guide&utm_source=apikeys-guide&utm_medium=web&utm_campaign=api-keys), for instance, handles metering, quota enforcement, and Stripe billing at the gateway layer. Building metering and billing on top of a custom key system is a significant additional investment.

## The Hidden Costs of Building

Teams that choose to build often underestimate the ongoing cost. The initial implementation is the smaller part; the operational tail is where the real expense lives.

**Cache invalidation.** Your key validation layer will use a cache for performance. When a key is revoked, every cache node needs to be invalidated. Cache invalidation bugs are notoriously difficult to diagnose; they manifest as "the key was revoked but requests are still going through" and may affect only specific nodes or regions.

**Replication lag.** If your API serves multiple regions, key data needs to replicate across them. During the replication window, a revoked key may still be valid in some regions. You need to decide on your consistency model and build accordingly.

**Rotation automation.** Supporting [zero-downtime rotation](/docs/security/key-rotation) means your system must handle overlapping key validity, grace-period tracking, and automated notifications. This is a state machine that interacts with your key store, notification system, and potentially your customers' deployment pipelines.

**Leak response.** When a key is leaked, the response needs to be fast: detect the leak, verify the key is active, revoke it, notify the owner, log the event. If any step in that pipeline is manual, response time is measured in hours, not seconds.

**Schema migrations.** As your key system evolves (adding scopes, expiration, metadata, tags), you will migrate the underlying data store. Migrations on a table that is queried on every API request need to be zero-downtime, which adds engineering complexity.

**On-call burden.** The key validation path is on the critical path of every API request. If it goes down, your entire API is down. That means your key system needs its own monitoring, alerting, and on-call rotation.

## The Hidden Costs of Buying

Managed solutions have their own cost profile that is easy to overlook.

**Vendor lock-in.** Your key format, consumer model, and management API will be shaped by the platform. Migrating away means re-issuing keys to every consumer, coordinating updates across their integrations, and running a parallel auth path during the transition. That is a project that can take months and introduces its own risk.

**Pricing at scale.** Managed platforms charge for what they manage. At low volume this is a bargain; at high volume it can become your largest infrastructure cost. Get pricing estimates for your projected scale before committing, and check how the pricing model changes at contract renewal.

**Feature gaps.** No managed solution covers every use case. You may need custom scoping logic, non-standard key formats, or integration with an internal identity system that the platform does not support. Workarounds for feature gaps (custom middleware that re-checks scopes after the gateway, scripts that sync key metadata from your database to the platform) can be as costly as the features themselves.

**Reduced visibility.** When something goes wrong in a managed system, you depend on the provider's logging, status pages, and support channels. You cannot read the source code, add debug logging, or trace the exact code path that handled a specific request. When a customer reports that their valid key was rejected, your debugging toolkit is limited to what the vendor exposes.

**Outage dependency.** If the managed platform has an outage, your API auth is down. Unlike an internal outage where you can deploy a hotfix or temporarily fail open for trusted traffic, a vendor outage leaves you with no levers to pull. Your incident response becomes "check their status page and update your own." Your SLA is bounded by their SLA.

## A Decision Framework

Use this matrix to evaluate your situation. It is not a formula; it is a set of signals that tend to push in one direction or the other.

| Signal | Points toward building | Points toward buying |
| --- | --- | --- |
| Number of services behind auth | 1-2 | 3+ |
| Team has platform/infra engineers | Yes | No |
| Custom key format or identity model required | Yes | No |
| Data-residency constraints | Strict | Flexible |
| Time to production | Months are acceptable | Weeks or less |
| Request volume | Billions/month (cost-sensitive) | Millions/month or less |
| API is a revenue source (monetized) | Neutral | Strong signal to buy |
| Existing infra (cache, proxy, monitoring) | Already in place | Would need to build |

The service-count row deserves explanation: with one or two services, the key system is simple enough that middleware handles it cleanly. At three or more services, the management overhead (per-service scopes, multiple rate-limit policies, cross-service revocation propagation) grows faster than linearly, which is where centralized infrastructure starts earning its cost.

Most teams land somewhere in the middle. A common pattern is to start with a managed solution to validate the product, then evaluate whether to bring the key system in-house as scale and requirements become clearer. The reverse path is equally common: teams build a minimal system first, then migrate to a managed platform when the operational burden outweighs the control.

## Hybrid Approaches

Build-vs-buy is not always a binary choice. Some teams adopt a managed gateway for external-facing auth while handling internal service-to-service auth with their own middleware. Others use a managed key store but write their own rate-limiting and scoping logic on top of it.

A common hybrid pattern: use a managed gateway for key validation and rate limiting at the edge, but store key metadata and scoping rules in your own database. The gateway handles the hot path (is this key valid? is it rate-limited?) while your application queries its own data store for authorization decisions (does this key's consumer have access to *this specific resource*?). This keeps the high-throughput validation path off your on-call rotation while preserving control over business-logic authorization. [Zuplo](https://zuplo.com/docs/articles/api-key-authentication?ref=apikeys-guide&utm_source=apikeys-guide&utm_medium=web&utm_campaign=api-keys) supports this pattern natively: after authenticating a key at the edge, it injects the consumer identity and custom metadata into the request context, so your backend receives pre-authenticated requests with the data it needs for fine-grained authorization.

The key question for any hybrid approach: where does the source of truth for key state (active, revoked, scopes, metadata) live? If it is split across systems, you inherit the synchronization and consistency challenges of both, which can be worse than committing fully to one approach.