Gateway lifecycle
Panicly’s gateway is not a thin proxy. It is an auth layer, quota layer, rules layer, control layer, logging layer, and provider-forwarding layer.
Request sequence
Receive provider-compatible request
The client sends a request to /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/completions, /v1/messages, /v1/models, /v1/panicly/models, or a provider namespace such as /v1/openrouter/*.
Authenticate the Panicly key
The gateway accepts a key through Authorization or x-panicly-key, then verifies it against stored key prefix and SHA-256 hash.
Evaluate plan and quota
The gateway checks workspace plan tier, included monthly volume, credit-backed capacity, and any configured usage offset.
Evaluate policy
Network Controls, Region Rules, model rules, Kill Switch, burst protection, abuse detection, token guard, and loop guard can block before upstream spend.
Core endpoint contract
Request
Authentication fields
Use Bearer pk-live-... for live traffic or Bearer pk-dev-... for development traffic.
Alternative direct key header for applications that cannot easily set a bearer token.
Provider model identifier, such as openrouter/auto or a connected provider-specific model.
Provider namespaces
Panicly can infer a provider from the model name or use a provider namespace such as /v1/openai/*, /v1/anthropic/*, /v1/openrouter/*, /v1/google/*, or /v1/vercel/*.