API Rate Limits, Queues, and Webhook Retries in High-Volume E-Commerce Stores

Why Synchronous Checkout Hooks Fail During Flash Sales

A typical e-commerce store connects its storefront to four or five external systems: an ERP for inventory, a 3PL warehouse for fulfillment, a CRM for email marketing, and an accounting tool for tax reporting. In many stores, developers attach synchronous HTTP calls directly to the order creation hook.

When normal traffic is ten orders an hour, synchronous calls work fine. When a Black Friday email blast generates four hundred orders in three minutes, the ERP API returns HTTP 429 Too Many Requests, checkout requests time out, and paid orders fail to reach the warehouse.

Decoupling Webhook Ingestion From Downstream API Execution

To make an e-commerce integration resilient under peak load, the webhook receiver must do almost no work during the incoming HTTP request. When Shopify or WooCommerce fires an order.created webhook to our Laravel middleware, our controller verifies the HMAC cryptographic signature, writes the raw JSON payload to a database inbox table, and returns HTTP 200 OK in under fifty milliseconds.

Background Horizon workers then pull those stored events from the queue and push them to the ERP and warehouse APIs at the exact pace those downstream servers can handle.

• Verify HMAC-SHA256 signatures on every incoming webhook and reject unauthenticated requests immediately.
• Deduplicate webhook deliveries by storing the unique event ID or order-status composite key in PostgreSQL.
• Configure Redis token-bucket rate limiters on outbound jobs to match Shopify, NetSuite, or ShipStation API quotas.
• Alert engineering channels in Slack only after a job exhausts its exponential retry schedule and enters the failed queue.

Respecting Leaky-Bucket Rate Limits Without Dropping Jobs

Platforms like Shopify GraphQL and NetSuite enforce strict concurrency and leaky-bucket point limits. If ten queue workers fire parallel requests against the same merchant token, nine of them will fail with rate limit errors.

We use Laravel Redis rate limiting middleware on our outbound job classes to pace requests automatically. If the downstream API bucket is ninety percent full or returns a Retry-After header, our worker releases the job back onto the queue with the exact delay requested by the upstream server.

Idempotency Keys and One-Click Dead-Letter Replay

Because webhook providers retry delivery whenever a network blip occurs, your integration will inevitably receive the same order webhook twice. We enforce database-level unique constraints on external order IDs so a duplicate webhook never creates two shipments.

We also build a lightweight integration dashboard where operations staff can inspect any failed sync payload, fix a missing SKU mapping in the ERP, and replay the held orders with a single click.

We also log response latency percentiles for every connected third-party API endpoint. When an ERP vendor degrades after a software patch on their side, your operations team has hard timestamped evidence to share with their support engineers.