Asttero

Shopify Webhooks and API - How to Design Reliable Integrations

Shopify webhooks and API - how to design reliable integrations

Scaling e-commerce beyond roughly PLN 100,000 monthly revenue requires moving from simple plug-ins to advanced system integrations. Stable data flow between Shopify and ERP, WMS, or PIM systems depends on correct use of API and webhooks. Designing such connections is an architectural challenge that must account for platform limits, event asynchronicity, and strict security standards. Understanding mechanisms such as the leaky bucket algorithm and HMAC verification prevents technical problems including duplicated transaction records, delayed inventory updates, and lost events during peak store load.

Challenges of integrating e-commerce with external systems

In large online stores, every second of downtime or data sync error translates into real financial loss and eroded customer trust. At high transaction volume, standard connectors often prove insufficient due to limited throughput and weak error handling. The core challenge is maintaining data consistency in a distributed environment where Shopify is the sales front and external systems handle logistics and accounting. Inconsistencies raise operational costs through manual record correction and explaining inventory mismatches to buyers. Before technical implementation, it is critical to plan Shopify integrations with external systems to define which data must move in real time and which can be batch-processed. Poor architecture creates technical debt that surfaces at the worst moments-such as Black Friday sales peaks.

API vs. webhooks in Shopify: two pillars of system communication

Communication between Shopify and external systems uses two complementary models: pull (API) and push (webhooks). The right mechanism depends on business process character and data freshness requirements. Comparison:

When to choose API polling?

Pull means the external system actively queries Shopify Admin API to fetch or update information. It suits processes that do not need instant reaction-such as inventory sync every 15 minutes or periodic sales reports. Polling gives full control over timing and intensity. Example: an ERP process that once daily pulls the full product list to reconcile closing stock. With very large catalogs, polling can be inefficient due to query limits and full-scan duration.

The role of webhooks in real time

Webhooks work in push mode-Shopify notifies the external system immediately after an event such as a new order or product update. They are essential for time-critical processes: WMS stock reservation right after purchase or payment status changes that trigger automated customer notifications. Webhooks remove the need for constant API polling, saving resources-but require high integrator server availability and capacity for sudden traffic spikes, such as a new collection launch.

Understanding Shopify API limits: how the leaky bucket works

Shopify uses rate limiting based on the leaky bucket algorithm to keep the platform stable for all merchants. Imagine a container (bucket size) that receives requests and drains at a fixed rate (leak rate). If requests arrive faster than it drains, the bucket overflows and further requests are rejected. When standard solutions lack required throughput, direct Shopify API use for ERP connection enables full control over data flow and query cost optimization.

REST Admin API vs. GraphQL Admin API

Strategies for handling query limits and 429 errors

Exceeding API limits returns HTTP 429 (Too Many Requests). Professional integrations must handle this without breaking the process. Monitor the X-Shopify-Shop-Api-Call-Limit response header (REST) or throttleStatus in GraphQL responses for remaining capacity and renewal time. On 429, implement exponential backoff-pause sending, then retry at increasing intervals (e.g. 1s, 2s, 4s, 8s). For complex business rules and high limits, building a dedicated Shopify app often queues work and processes tasks asynchronously without blocking the main communication thread.

Designing reliable webhooks: queue-based architecture

The most common webhook mistake is running heavy business logic (ERP writes, PDF generation, notifications) directly in the receiving endpoint. Shopify requires a 200 OK response within 5 seconds. Exceeding that marks the attempt failed-which at scale can paralyze integration. Correct flow: Webhook → Endpoint → Queue (e.g. Redis) → Worker → ERP system.

Retry policy and subscription deletion risk

Shopify applies a strict retry policy. Without a correct response, it retries webhook delivery up to 8 times within a 4-hour window. If the endpoint still fails, that webhook subscription is permanently removed. Prevent this with async architecture: the endpoint receives the webhook, writes raw data to a fast queue (Redis, RabbitMQ), and immediately returns 200 OK. A separate worker performs ERP integration. That allows safe processing even during brief ERP unavailability.

Security and data consistency: HMAC verification and idempotency

E-commerce integrations handle sensitive customer and financial data, so security is paramount. Every public endpoint receiving Shopify data must block unauthorized requests that could inject fake orders or leak inventory information.

X-Shopify-Hmac-SHA256 signature verification

Every Shopify webhook over HTTPS includes X-Shopify-Hmac-SHA256-a digital signature of the request body using a shared secret. The receiver must compute HMAC from the raw body and compare it to the header. Mismatch means reject the request as a potential attack or transmission error. This is critical for data integrity and prevents fake events in ERP.

Ensuring idempotency (X-Shopify-Webhook-Id)

Due to network retries, the same webhook may arrive more than once. Without protection, that can duplicate orders in accounting or ERP. Idempotency means repeated execution of the same operation yields the same result. Use unique header X-Shopify-Webhook-Id and store processed IDs. On duplicate delivery, return 200 OK but skip business logic. Such mechanisms affect how much time and resource a stable system connection requires.

Summary: checklist for a stable Shopify integration

FAQ

What is the difference between API and webhooks in Shopify?

API is pull: the external system actively fetches data from Shopify. Webhooks are push: Shopify automatically notifies the external system immediately after an event, such as a completed customer transaction.

What are API query limits for Shopify Plus?

Shopify Plus REST Admin API limit is 20 requests per second-ten times Standard (2 req/s). GraphQL limit is 500 cost points per second.

Why does Shopify delete webhook subscriptions?

A subscription is removed if the target server does not respond correctly (2xx status) after repeated attempts over an extended window. This protects Shopify infrastructure from sending data to dead endpoints.

How do I verify a Shopify webhook is authentic?

Compute HMAC-SHA256 from the raw request body using the app Shared Secret and compare the result to the value in X-Shopify-Hmac-SHA256.

What is idempotency in the webhook context?

A property ensuring multiple deliveries of the same notification do not cause technical errors such as duplicate orders in external systems-implemented by checking unique X-Shopify-Webhook-Id before processing.

How do I handle 429 Too Many Requests in an integration?

Implement request queuing and exponential backoff, pausing further requests for the duration indicated in response headers so API limits can renew.

Bibliography