The middleware

import { Hono } from "hono";
import { createMiddleware } from "hono/factory";

type Customer = { id: string; perMinute: number };

// SHA-256 of each issued key -> customer. Store hashes, never the raw keys.
const keys = new Map<string, Customer>();

async function sha256Hex(value: string): Promise<string> {
  const digest = await crypto.subtle.digest("SHA-256", new TextEncoder().encode(value));
  return [...new Uint8Array(digest)].map((b) => b.toString(16).padStart(2, "0")).join("");
}

// One fixed one-minute window per customer, kept in memory.
const windows = new Map<string, { start: number; count: number }>();

const apiKeyAuth = createMiddleware<{ Variables: { customer: Customer } }>(async (c, next) => {
  const header = c.req.header("authorization") ?? "";
  const key = header.startsWith("Bearer ") ? header.slice(7) : c.req.header("x-api-key");
  if (!key) return c.json({ error: "missing_api_key" }, 401);

  const customer = keys.get(await sha256Hex(key));
  if (!customer) return c.json({ error: "invalid_api_key" }, 401);

  const now = Date.now();
  const windowStart = now - (now % 60_000);
  const previous = windows.get(customer.id);
  const current = previous && previous.start === windowStart ? previous : { start: windowStart, count: 0 };
  if (current.count >= customer.perMinute) {
    const retryAfter = Math.ceil((windowStart + 60_000 - now) / 1000);
    return c.json({ error: "rate_limited" }, 429, { "Retry-After": String(retryAfter) });
  }
  current.count += 1;
  windows.set(customer.id, current);

  c.set("customer", customer);
  await next();
});

const app = new Hono<{ Variables: { customer: Customer } }>();
app.use("/v1/*", apiKeyAuth);
app.get("/v1/me", (c) => c.json({ customer: c.get("customer").id }));

Callers send their key as Authorization: Bearer <key>, or in x-api-key. The middleware hashes the key, looks up the customer, and counts the request against that customer's limit for the current minute.

A few choices worth keeping even if you change everything else:

• Store hashes, not keys. If the key table leaks, a SHA-256 of a long random key is useless to whoever has it. Show the raw key to the customer once, when you create it.
• Limit per customer, not per IP. A customer running jobs from a few servers shares one budget, and two customers behind the same NAT don't throttle each other.
• Send Retry-After with the 429. Well-behaved clients wait for it instead of retrying immediately.
• Return 401 for a missing or unknown key. Keep 403 for a key you recognise but whose customer isn't allowed in, such as a suspended account.

I ran it against Hono 4.13 with a limit of 2 per minute: no key got 401, an unknown key got 401, the first two calls got 200, and the third got 429 with a Retry-After header.

What this version leaves out

It works on one process. Past that, the gaps show up quickly:

• More than one instance. Each process has its own windows map, so three instances let a customer make three times their limit. You need a shared counter (Redis, or your database) or a limit divided by the number of instances.
• Burst at the edge of a window. A fixed window lets a customer send their full limit at 12:00:59 and again at 12:01:00. A sliding window or token bucket smooths that out.
• Key management. Customers need to create, rotate and revoke their own keys, and a revoked key has to stop working everywhere, not only after a restart.
• Monthly quotas. "1,000 requests per minute" and "100,000 requests per month" are different counters. The monthly one has to survive restarts and decide what happens at the limit: stop, or bill the overage.
• Billing. If customers pay by usage, the counts have to reach your invoices without losing any or counting any twice.

Each of these is a reasonable afternoon on its own. Together they're a small product.

The same thing with UsageRail

I work on UsageRail, which is that product for teams that already bill with Stripe. Its Hono middleware checks the key, rate limit and quota inside your process, so requests never go through a proxy, and counts usage per customer:

import { serve } from "@hono/node-server";
import { Hono } from "hono";
import { usageRail, type UsageRailVariables } from "@usagerail/node/hono";
import { fileSnapshotStore, flushOnExit } from "@usagerail/node/node";

const appKey = process.env.USAGERAIL_APP_KEY!;
const rail = usageRail({
  appKey,
  auth: "api-key",
  snapshotStore: fileSnapshotStore(appKey),
});
flushOnExit(rail.engine);

const app = new Hono<{ Variables: UsageRailVariables }>();
app.use("*", rail);

app.post("/v1/generate", async (c) => {
  const result = await generate(await c.req.json());
  c.get("usageRail").track(result.tokens); // optional: count tokens
  return c.json(result);
});

serve({ fetch: app.fetch, port: 3000 });

Limits, quotas and plans are set in a console instead of code, and your customers manage their own keys in a hosted portal. On Node.js, flushOnExit matters: without it, counts that haven't been sent when the process stops are lost and never billed. The details, including Hono on Cloudflare Workers, are in the docs on metering and rate limits for Hono APIs.

If you only need API keys and a per-customer rate limit in one process, keep the first version.