Technology / Integrations
Most 3PL integration breakage is not API breakage. It is mismatch between the channel's promise to the customer and the warehouse's actual SLA. This page summarizes how Warpspeed integrates with each major platform, what we treat as the source of truth, and where the rough edges are.
TL;DR
Section 01
Every connector we run looks the same from far enough away. There is an event surface for "something happened on the platform", a sync surface for "give me the canonical version", and a write surface for "here is the fulfillment update". The interesting work is in handling the edges where those three disagree.[11]
The same five layers across every connector, regardless of platform.
| Layer | What we do | Failure mode we plan for |
|---|---|---|
| Event surface | Subscribe to webhooks or notifications | Webhook drops; we run a reconciliation pull |
| Sync surface | Fetch the canonical record by ID | Stale read inside platform replication; we retry with backoff |
| Write surface | Post fulfillment, tracking, inventory deltas | Throttling; we batch and respect rate-limit headers |
| Reconciler | Periodic full diff between platform and WMS | Found a missed event; we replay it |
| Audit log | Persist every inbound and outbound payload | Customer dispute or audit; we replay or export |
“The integration question is not "did we get the webhook". It is "if we missed it, would we know within 30 minutes". A reconciler is not optional.”
Each platform calls these layers something different. Shopify webhooks and the GraphQL Admin API are the event and sync surfaces; FulfillmentOrder graph is the write surface. Amazon SP-API splits them across Notifications, Reports, and direct REST. WooCommerce uses webhooks and the v3 REST API. BigCommerce ships with a similar event-and-fetch model but cleaner API shapes. The vocabulary changes; the architecture does not. Once a connector library has solved the five layers for two platforms, the third and fourth are mostly translation work, not redesign.[14]
Reconciliation feels expensive until the first time it catches an outage the alerting missed. An hour-long network problem at the platform's webhook delivery layer can lose 200 orders without firing a single alert on our side, because no failed delivery means no failed-delivery metric. The reconciler is the only system that catches the absence of events. Across the connectors we run, the reconciler resolves more incidents than every other monitoring source combined, by a wide margin.
Section 02
First-class fit for DTC brands. We register as a fulfillment service per location, use the FulfillmentOrder graph for tracking back, and post inventory deltas through inventoryAdjustQuantities.
Self-hosted WordPress means hosting matters. We pull orders through the v3 REST API, push fulfillment back, and use scheduled reconciliation because webhook reliability depends on the host.
Strong API, good webhook reliability, native multi-storefront support. We sync orders through API V3 and use Channels API to keep multi-storefront inventory honest.
Heavier lift than Shopify. We work with Adobe Commerce Cloud and self-hosted Magento 2.4+ via the REST API and recommend the Async Bulk API for backfills over a few thousand records.
Marketplace SLAs are tight. We meet the to-ship-within-72-hours requirement, return tracking through the fulfillment API, and handle the 14-day return window expectations.
FBA, MCF, and FBM live in the same SP-API surface but behave differently. We integrate at the Notifications and Orders endpoints and run FBA inbound through the FBA Inbound API.
Sell API splits inventory and fulfillment cleanly. We use the Inventory API for listings and the Fulfillment API for shipping back tracking, and watch the late shipment metric.
Lower volume per seller, fewer endpoints. We pull receipts (Etsy's term for orders), update tracking, and watch the on-time shipping metric for Star Seller eligibility.
We treat NetSuite as the system of record for product and customer master data. Orders flow either NetSuite to WMS, or storefront to WMS to NetSuite, depending on the brand's existing workflow.
Enterprise integrations are typically through OData APIs on S/4HANA Cloud or through IDocs on older ECC environments. We support both via middleware adapters.
Section 03
For Shopify, WooCommerce, BigCommerce, and Adobe Commerce, our default architecture is webhook-triggered with reconciliation. The customer promise is fast handling and accurate tracking notifications. The integration priority is a tight order-to-pick lag and a tight pick-to-tracking lag.[1]
For Amazon, eBay, TikTok Shop, and Etsy, the integration is shaped by the platform's account-health metric, not by customer experience. Late shipment rate, valid tracking rate, and on-time delivery rate decide whether the seller stays on the platform.[6][7] We treat handling time as a hard contract, not a target.
For NetSuite and SAP, the integration shape is reversed. The ERP is the system of record for product, customer, and finance. Orders may originate there or flow through it for accounting after fulfillment. Sync cadence is nightly batch plus event-driven exception, not sub-second streaming.[9][10]
The brand's promised cutoff time is the single number that decides whether a marketplace SLA is achievable, whether a Shopify customer's "ships today" promise can be kept, and whether the warehouse staffing schedule works. We treat cutoff as a contract per channel, not a goal. A 3PL operating Amazon FBM with a 4pm cutoff can only ship out for the same day if every order arriving before 4pm is ship-confirmed by 6pm; if the warehouse is picking that batch at 5:45pm, the SLA is structurally at risk on every busy day. We size capacity backward from cutoff, not forward from order count.
When a brand sells the same SKU on Shopify, FBA, FBM, TikTok Shop, and eBay, the question of which channel sees what stock becomes operational. The default we recommend is one pool, advertised everywhere. The exceptions are FBA (which holds its own physical pool inside Amazon's network), wholesale reservations (which set aside units against a known ship date), and pre-orders (which advertise virtual inventory backed by a forecast). Anything else collapses to a single sellable count, kept in the WMS and pushed to every channel.
Section 04
Across every brand we onboard, the same question recurs. Who owns the authoritative inventory number? The answer that produces the fewest oversell incidents is "the WMS". Storefronts and marketplaces hold cached numbers we keep refreshing.
Default inventory flow direction by event.
| Operation | Source | Destination | Cadence |
|---|---|---|---|
| Receive at warehouse | WMS | All connected platforms | Streaming on receive event |
| Pick or adjust | WMS | All connected platforms | Streaming on event |
| Cycle count or audit | WMS | All connected platforms | Bulk update on count complete |
| Manual platform edit | Platform admin | WMS via reconciler | Hourly diff or webhook |
| FBA inbound or removal | Amazon SP-API | WMS | Daily report pull |
The exceptions are bonded inventory at Amazon FBA and inventory in transit between locations. Amazon's reported quantity may lag what the WMS thinks it sent, especially during peak. Reconcilers handle this by treating Amazon's number as authoritative for FBA-specific stock and the WMS as authoritative for everything else.[6]
When demand briefly outruns supply, allocation order matters. The default we run is first-in-first-out by paid timestamp, with three exceptions. Pre-orders are honored against scheduled inventory rather than current stock. Wholesale and retail orders are honored against contractually reserved units. Marketplace SLA-bound orders (Amazon FBM Prime, TikTok Shop within the 72-hour window) get priority over DTC orders with longer promises. The brand sees the allocation policy in their console and can adjust it, but the default catches most cases.
The other axis of allocation is geography. With multi-warehouse brands, the WMS routes each order to the warehouse closest to the destination ZIP that holds the inventory and meets the channel's cutoff. Splitting orders across warehouses is allowed but cost-managed; we surface a per-order estimated split fee to the brand console so they can see the trade-off. Most DTC orders ship from a single warehouse, but Marketplace orders with tight deadlines occasionally split.
Section 05
The mechanical part of onboarding an integration is small. The hard part is data quality. Catalog drift, missing weights, missing dim, missing HS codes, missing brand-supplied images, and stale variant titles all show up the moment the connector is enabled.
Pages worth reading next: Shopify integration setup, WooCommerce integration, BigCommerce integration, and TikTok Shop integration.
Section 06
Every connector we run treats every inbound event as at-least-once. Webhooks can be delivered twice. Replays can fire while the original is still processing. A network blip during an HTTP write can leave the call ambiguous (the request may have succeeded, failed, or partially landed). The integration shape that works under these conditions is idempotent by construction.[12]
For order ingestion, the platform's order ID is the natural idempotency key. The work-order table has a unique constraint on platform_id plus platform_order_id, and an "if exists, no-op" path before insert. For inventory deltas, the WMS uses an event ID generated at the moment of receive, pick, or adjustment; the connector replays the same event ID without effect. For outbound writes (tracking, fulfillment, shipment confirmation), we use the platform's optional idempotency-key header where one exists, and a hash of the business payload where it does not.
Retries use exponential backoff with jitter. Five attempts over roughly fifteen minutes covers most transient errors. After five attempts, the event goes to a per-platform dead-letter queue with a bounded depth and a page on the on-call rotation. Dead-letter depth is the most useful single health signal we monitor; a non-zero queue is a story, and a growing queue is an outage.
Section 07
We instrument every platform connector with the same metric set. Different names per platform, same shape. The point is to be able to compare "Shopify is slow today" against "WooCommerce is slow today" without translating between vocabularies.
The eight metrics that catch most integration problems before the brand notices.
| Metric | What it tells you | Alert threshold |
|---|---|---|
| Webhook ingest rate | Events received per minute, per topic, per shop | Drop of more than 50 percent vs trailing-hour baseline |
| Webhook ingest success | 2xx response rate from our receiver | Below 99 percent for 5 minutes |
| HMAC verification failure rate | Bad signature ratio, per platform | Above 0.1 percent |
| Reconciler delta | Records found by reconciler not previously in WMS | Investigate at first non-zero, page above 50 per hour |
| Outbound write latency P95 | Time from event to platform-confirmed write | Above platform-specific budget |
| Rate-limit headroom | Remaining budget per shop, per platform | Below 20 percent for 10 minutes |
| Dead-letter depth | Events that exhausted retries | Non-zero is a story; growing is an outage |
| Catalog drift count | SKUs with mismatched weight, dim, HS code | Daily review, not paged |
We publish per-connector SLOs to the brand admin: order ingest P50 under 5 seconds, fulfillment write P50 under 10 seconds, reconciler delta resolved within 24 hours. The brand can see the rolling 30-day attainment in the same console where they review their own operations. Surfacing these numbers does two things: it builds trust on good days, and it pre-frames the conversation on bad days. A brand that already knows the connector missed an SLO is a calmer phone call than one that hears it from a customer support escalation.
Section 08
Every connector holds long-lived credentials. The blast radius of a leaked token is large: full read on a brand's order history, often write on inventory and fulfillment, sometimes access to PII. Treating credentials casually is the mistake that ends an integration partnership.
Tokens live in a dedicated secrets vault, encrypted at rest with a key that rotates quarterly. The connector reads tokens at request time, never logs them, and uses short-lived in-memory caches with a TTL measured in minutes. Tokens are scoped to the minimum permissions the connector actually exercises. We refuse "give me write_everything" scopes even when the platform admin offers them, because the wider the scope, the longer the audit trail we have to defend.
Every inbound webhook is verified by HMAC against the platform's signing secret. Bodies that fail verification are logged and dropped, not retried, not forwarded. This catches both accidental misconfiguration and the occasional hostile actor probing for unsigned endpoints. The signing secret is itself rotated whenever a credential rotation event happens, even if the trigger was unrelated.
The audit log captures every inbound and outbound payload, the credential identifier used, the latency, and the outcome. It is append-only and retained for one year hot, seven years cold. Brands with SOC 2, ISO 27001, or PCI obligations can request an extract for their own audit. We have shipped these extracts on a few hours' notice during external audits, which is the test of whether the system actually works.
“The security posture of a 3PL connector is the security posture of the brand using it. There is no separate posture; brand customers see the security as one piece.”
Section 09
Integrations fail. Sometimes the platform has an outage. Sometimes a brand-side admin rotates a credential without telling anyone. Sometimes a new app on the brand's storefront starts writing to inventory. The shape of the response decides whether the brand notices.
The seven failure shapes we have a runbook for, and what the on-call does in the first hour.
| Failure | First detection | First-hour response |
|---|---|---|
| Platform outage | Webhook ingest rate drops, status page confirms | Switch to polling, surface in brand console, do not retry storm |
| Credential expired | Outbound 401 on first write attempt | Page brand admin, queue events, resume on rotation |
| Rate-limit hit | 5xx or 429 with retry-after header | Slow our writes, prioritize the brand's traffic over our backfill |
| Inventory desync | Reconciler delta jumps | Quarantine writes for affected SKUs, run targeted reconcile |
| Webhook signature failure spike | Verification failure rate metric | Investigate signing secret, re-register endpoint |
| Brand-side admin edit gone wrong | Reconciler finds out-of-band changes | Surface in audit log, ping brand admin, replay if needed |
| Catalog explosion | Backfill volume spike or cost-point burn | Switch to bulk operations, throttle non-critical writes |
The single biggest difference between a young integration team and a mature one is whether the runbook exists and gets used. We carry a runbook entry per failure shape, written in the language an on-call engineer can act on at 3am. Each entry has a detection signal, a triage checklist, a remediation procedure, and a post-incident review template. Most of our incidents are resolved without a brand call because the runbook routes to a fix the on-call has done before.[13]
Talk to us
We have onboarded brands running every combination on this page. Send us a short note about your storefront, marketplaces, and ERP and we will tell you exactly what the connector cutover would look like.