Wrapping an API you can't expose
A small server whose only job is holding a key.
Build time ~2 hrs
You have a browser app that needs to call a paid API. The key can't go in browser code. The answer is a small proxy — often a single serverless function — and it's one of the most common shapes in vibe-coded projects.
1. It does four things
Authenticate the caller. Check they're within limits. Call the upstream API with your key. Return the result.
Keep it to that. A proxy that grows business logic becomes a second application you have to maintain.
Build a proxy endpoint for <upstream API>. Stack: <serverless function / small server>. - Upstream key in an environment variable, server-side only. - Accept only the specific parameters my app sends. Validate each and reject anything else — never pass the client's request through wholesale. - Rate limit per <user / IP / session>. Say what limit and how you're storing the counter. - A hard daily spend or call cap, across all users, that fails closed. - CORS locked to my own origin, not "*". - On upstream failure: retry only what's retryable, then return a clear error. Never leak the upstream's raw error to the client. Log every call with enough detail to work out who spent what.
2. Never forward the request as-is
The mistake that turns your proxy into a free API for the whole internet. If you accept whatever the client sends and pass it upstream, someone will find it and use your key for their own purposes.
Accept a specific, named set of parameters. Validate each. Build the upstream request yourself.
3. Cap the spend
An upstream that charges per call, reachable from a public page, with no cap, is an open invitation. Set a daily ceiling that stops serving when hit, and alert yourself when it's approached. This has ruined people's months.
4. Cache where you can
If the same request produces the same answer for a while, cache it. On a proxy this is directly money saved, and it's often trivial — a short-lived in-memory cache keyed on the parameters.
Watch the logs for the first week after launching publicly. You'll find out quickly whether anyone has found the endpoint and what they're doing with it.