Running a Seller API integration on serverless platforms, containers, and edge workers — cold starts, connection reuse, secrets, and webhook timeouts.
What this covers#
Operational guidance for AWS Lambda, Azure Functions, Google Cloud Functions, Cloudflare Workers, and long-lived containers. Product names here are platforms you choose; Avrix only requires HTTPS outbound to the Seller API and an HTTPS endpoint for webhooks.
Shared principles#
- Keep the API key in the platform secret store; inject at runtime.
- Reuse HTTP clients across invocations when the runtime allows (module scope / static clients).
- Honour
Retry-Afteron 429/5xx — see API clients. - Return
2xxfrom webhook handlers quickly; do heavy work asynchronously.
Serverless functions#
| Concern | Guidance |
|---|---|
| Cold start | Init the HTTP client outside the handler when possible |
| Timeouts | Set function timeout above Avrix request timeout + retry budget |
| Concurrency | Cap parallel POST /orders if you risk double-charge races in your app |
| Secrets | Platform secret refs → env (AVRIX_API_KEY, AVRIX_WEBHOOK_SECRET) |
AWS Lambda / Azure Functions / Cloud Functions#
- Prefer provisioned concurrency or min instances for checkout-critical paths.
- Do not open a new TCP connection per request inside a hot loop.
- Log
X-Request-Idand yourorderReferencetogether.
Cloudflare Workers (and similar edge runtimes)#
- Edge is fine for signature verification and enqueueing; prefer a durable backend for order creation if you need longer retries or DB transactions.
- Respect CPU/time limits — do not run multi-minute reconciles on the edge.
Containers and VMs#
Long-lived processes are the simplest place for:
- Catalog sync cron / workers
- Webhook consumers with backoff
- Connection pooling for high QPS
Scale horizontally behind your load balancer; each replica reads the same secret. Avoid baking keys into images.
Webhook delivery timeouts#
Avrix expects a prompt HTTP response. If your platform’s ingress timeout is short:
- Verify signature.
- Persist the delivery id (or event id) for idempotency.
- Enqueue work.
- Return
2xx.
Slow synchronous fulfilment inside the webhook request causes retries and duplicate processing pressure — design for at-least-once delivery.
Config checklist per environment#
| Item | Sandbox deploy | Production deploy |
|---|---|---|
| API key environment | sandbox | production |
| Base URL | https://api.avrix.io | https://api.avrix.io |
| Webhook URL | pre-production HTTPS endpoint | production HTTPS endpoint |
| PSP | test mode | live mode |
Confirm with GET /whoami after every cutover — see Environments.
Common mistakes#
- Embedding production secrets in CI logs or container layers.
- Using a browser-origin Worker that exposes the Seller API key.
- Letting webhook handlers exceed the platform timeout without a queue.
Next steps#
- Secrets and config — rotation
- Monitoring and support — alerts and escalation
- Go-live — production cutover