API key auth for serverless functions at the gateway
Enforce API key authentication at the gateway layer before your function handler code runs—no middleware to write per function, no accidental open endpoints, and key rotation that does not require a redeploy. Scope different keys to different routes for multi-tenant and internal API patterns.
Last updated: 2026-04-20
Answer first
Direct answer
API key auth for serverless functions at the gateway. Inquir enforces API key authentication at the gateway layer—the function handler code only runs after auth passes. There is no auth boilerplate in the handler; there is no way to accidentally deploy an unprotected endpoint if the route has auth enabled.
When it fits
- Public API endpoints that should never be accidentally open
- AI agent tool endpoints where the model uses a scoped API key per tool group
- Internal function-to-function calls where you want auth without handler boilerplate
Tradeoffs
- Each new function requires the developer to remember to add auth middleware. Code review catches some cases; production incidents catch the rest.
- Shared auth utilities (a validateApiKey() function) help but do not prevent the root cause: authentication is opt-in rather than opt-out.
Workload and what breaks
What happens without gateway-level auth
- Auth middleware in every function handler: duplicated logic, easy to forget on new routes
- Accidental open endpoints: deploy a function without adding auth middleware and it is publicly accessible
- Key rotation requires code changes: if the key is checked inside the handler, rotating it requires a redeploy
- No per-route scoping: one shared API key for all functions means rotation affects every caller simultaneously
Inline authentication in serverless function handlers is a common pattern that works until scale. When you have 20 functions and a security review, discovering that 3 endpoints are missing auth middleware because someone forgot to copy the pattern is an incident waiting to happen.
Trade-offs
Why per-function auth middleware is fragile
Each new function requires the developer to remember to add auth middleware. Code review catches some cases; production incidents catch the rest.
Shared auth utilities (a validateApiKey() function) help but do not prevent the root cause: authentication is opt-in rather than opt-out.
How Inquir helps
Auth at the gateway: opt-out, not opt-in
Inquir enforces API key authentication at the gateway layer—the function handler code only runs after auth passes. There is no auth boilerplate in the handler; there is no way to accidentally deploy an unprotected endpoint if the route has auth enabled.
API keys are workspace-managed. Rotate a key in the gateway config and it takes effect immediately for all routes using that key—no function redeploy needed. Scope different keys to different route groups for internal API vs. external partner access patterns.
What you get
Gateway auth features
Pre-handler enforcement
Auth check happens at the gateway before your function code runs. A bad key returns 401 without invoking the function—no billing, no handler execution.
Zero handler boilerplate
No middleware to add to each function. The handler assumes an authenticated caller; no auth logic in handler code.
Key rotation without redeploy
Rotate API keys in gateway configuration. Takes effect immediately for all routes using that key. No function code change needed.
Per-route key scoping
Different API keys for different route groups. Internal admin routes use a different key than partner-facing API routes.
What to do next
How to set up API key auth on Inquir
Enable API key auth on the gateway route
In the gateway config, enable API key auth for the route or route group. Specify which keys are valid for this route.
Distribute the key as a secret
Store the API key as a workspace secret for functions that call each other internally. Share externally via your own key management process.
Write handler assuming authenticated caller
Your function handler does not need to validate the API key—the gateway already did. Focus handler logic on business validation.
Code example
Handler code with gateway-level auth (no auth boilerplate)
The gateway validates the API key before this code runs. The handler can assume the caller is authenticated and focus entirely on business logic.
export async function handler(event) { // No API key validation needed — gateway already enforced auth // event.requestContext.identity.apiKeyId is available if you need key metadata const customerId = event.pathParameters?.customerId; if (!customerId) return { statusCode: 400, body: JSON.stringify({ error: 'customerId required' }) }; const customer = await db.customers.findById(customerId); if (!customer) return { statusCode: 404, body: JSON.stringify({ error: 'not found' }) }; return { statusCode: 200, body: JSON.stringify({ customer }) }; }
export async function handler(event) { // This route uses a different API key than the public routes // The key is scoped to internal tool callers (AI agent orchestrator) const { query } = JSON.parse(event.body || '{}'); const results = await search.query(query); return { statusCode: 200, body: JSON.stringify({ results }) }; }
When it fits
Use gateway-level API key auth for
When this works
- Public API endpoints that should never be accidentally open
- AI agent tool endpoints where the model uses a scoped API key per tool group
- Internal function-to-function calls where you want auth without handler boilerplate
When to skip it
- Endpoints that need user-level authentication (JWT/session) rather than service-to-service API keys—combine gateway API key auth with user auth in the handler for those
FAQ
FAQ
Can I use both API key auth and JWT auth?
Yes—enable API key auth at the gateway for service-to-service routes. For user-facing routes, validate JWTs inside the handler. Routes can use different auth models.
What happens to requests with an invalid API key?
The gateway returns 403 before the function handler runs. The function is not invoked and does not incur invocation billing.
How do I rotate a key if it is compromised?
Remove the compromised key from the gateway configuration and add a new one. Existing sessions with the old key fail immediately. Distribute the new key to legitimate callers via your secrets management process.