Ecommerce platform integrations

Assess an ecommerce integration by following an order, a stock change and a correction across every system that needs them. For each handoff, decide when it happens, which record is authoritative and how staff will find a missed update. An app listing or a delivered notification does not establish that the destination completed the work.

Map the handoffs

Keep payment, order and fulfilment states separate. An order may exist before payment is confirmed; a paid order may still await picking. Record how each destination identifies the original commerce order and what happens after an address correction, cancellation or partial refund.

Choose a connection method

A supported app may reduce build work if its documented events, fields and exception handling fit the proposed store. Ask whether it updates existing destination records, handles later changes and shows rejected transfers. Check the installed app, account and plan.

An API connection allows tailored mapping but needs an owner for credentials, changes, monitoring and recovery. A webhook can signal a change, while the receiver may need to fetch the current record.

Notifications can arrive out of order or be missed, so compare source and destination records independently. A reviewed manual export can suit a small operation if staff have a clear cut-off and a way to prevent duplicate imports.

Check the platform boundary

Shopify documents order webhooks and inventory states. When an order is placed, Shopify decrements available inventory and increments committed inventory; fulfilment decrements committed inventory.

WooCommerce core can notify an external service about order and product events, and provides delivery logs. Under its documented default, repeated delivery failures can disable a webhook. Its pending-payment and processing states mean different things; payment gateways may affect transitions.

BigCommerce documents order-created webhooks. Their callbacks contain a lightweight event description, and the documented order-created example identifies the order. An order-created event alone is not a dispatch rule.

WooCommerce automatically disables a webhook after more than five consecutive delivery failures. A response counts as successful for this purpose when it is a 2xx, 301 or 302 status; a 4xx or 5xx response counts as a failure. Confirm who will notice a disabled webhook and how its status will be checked.

BigCommerce calculates the callback hash from the JSON-encoded payload data to help detect duplicate events. Confirm that the receiver’s duplicate-handling approach matches the platform’s delivery details.

Compare the delivery contract

Shopify webhooks deliver near-real-time data for subscribed event topics; polling checks for changes through an API. Decide whether each handoff needs an event trigger or a periodic check.

Confirm that the subscription covers the event and that its payload includes the information the receiver needs. Shopify supports filters and include_fields to narrow deliveries.

A Shopify receiver should verify webhook HMAC signatures and ignore duplicate deliveries using the X-Shopify-Webhook-Id header. Include both checks in the proposed connection design; receiving a payload alone does not establish that it is authentic or new.

BigCommerce supports delivery over HTTPS, Google Cloud Pub/Sub and Amazon EventBridge. HTTPS destinations must use port 443, a new webhook can take up to one minute to work, and a subscription is deactivated after 90 days of inactivity. Check that the chosen delivery path suits the receiver and can be kept active.

BigCommerce data filters have a narrow documented boundary: they are available only through the GraphQL Admin API, currently support a metafield’s namespace field, and allow one filter with one value per webhook. REST webhook endpoints do not support filters, so confirm that the required event selection is possible through the proposed interface.

WooCommerce lets an administrator set a webhook’s topic, destination URL, secret and delivery status. Saving an active webhook sends a ping to its destination, which provides an initial connection check; it does not demonstrate that later event processing succeeds.

Platform-Specific Webhook Limits and Requirements

Require an observable result

For each flow, ask how staff see an item waiting, accepted by the destination, rejected or held for review. A successful webhook response may acknowledge receipt before later processing fails. Retries must be checked against existing destination records so they do not create another invoice, pick task or stock adjustment.

Agree how often to compare commerce orders with fulfilment and accounting records, which later changes the comparison includes and who closes exceptions. Before choosing a connection, ask the supplier to show the proposed configuration handling a paid order, an incomplete payment, a correction, a partial fulfilment and a refund. Record expected results first.