Amazon and Walmart Marketplace ERP Integration: Orders, Inventory, and Settlements

Adding Amazon and Walmart to a store that already runs on Shopify and an ERP sounds like “more of the same orders”. It isn’t. Marketplaces own the customer, enforce their own fulfillment deadlines, rate-limit APIs much harder than storefront platforms, and pay you net of fees on their own schedule. This guide covers the integration differences that matter and how to keep one ERP as the source of truth across channels. As on every page, documented marks statements from Amazon, Walmart, or official sources, and recommendation marks our guidance.

The architecture: one adapter per channel, one ERP

Recommendation: build a separate adapter for each channel (Shopify, Amazon, Walmart) that converts channel events into one internal order model, and keep everything else — inventory allocation, fulfillment, finance — in the ERP. Every order carries its channel, marketplace, and the channel’s order ID as a unique external reference. That prevents duplicates across retries and lets you report by channel. See event-driven architecture and preventing duplicate orders.

Amazon: notifications first, polling last

Documented: SP-API rate limits use a token bucket — a rate (requests per second added to the bucket) and a burst (maximum bucket size) — and can apply per account-application pair. For Orders API v2026-01-01, Amazon lists default limits of 0.0056 requests per second with a burst of 20 for searchOrders and 0.5 per second with a burst of 30 for getOrder. Amazon may grant higher limits to some selling partners, and you shouldn’t depend on the rate-limit header being present.

Documented: the ORDER_CHANGE notification reports order-level changes such as status updates and buyer-requested changes, and replaced the older order status notifications. Notifications are delivered to a destination you create — an Amazon SQS queue (after granting SP-API permission to write to it) or Amazon EventBridge.

Recommendation:

1. Subscribe to ORDER_CHANGE with an SQS destination and process messages from the queue.
2. For each message, fetch the order with getOrder (well within its higher limit) and upsert it into the ERP by Amazon order ID.
3. Run searchOrders on a slow schedule (for example hourly) for orders updated since your last checkpoint, purely as reconciliation.
4. Back off on HTTP 429 and spread backfills over time — the search limit makes large backfills slow by design.

Amazon also maintains the older Orders API v0. If you’re maintaining an existing integration, check Amazon’s migration guidance for the current recommended version.

Amazon: buyer PII and Restricted Data Tokens

Documented: operations that return personally identifiable information — such as buyer details and shipping addresses — are restricted and require a Restricted Data Token (RDT) obtained from the Tokens API, which is then sent in place of the regular access token for those calls.

Recommendation: request RDTs only for merchant-fulfilled orders where you need the address to ship, and only for the data elements required. Don’t copy buyer PII into systems that don’t need it (analytics, chat tools), and follow Amazon’s data protection requirements for retention.

Amazon: FBA vs. merchant-fulfilled

Recommendation:

• FBA (Fulfilled by Amazon): Amazon ships from its warehouses. Model FBA as a separate ERP location, record sales and cost of goods when Amazon ships, and reconcile FBA quantities with Amazon’s inventory data. Inbound shipments to FBA are stock transfers from your warehouse to that location.
• Merchant-fulfilled (MFN): you ship. The order flows to your warehouse or 3PL like any other channel, but with Amazon’s ship-by dates and the requirement to confirm shipment with tracking. Missing those windows affects your account health, so make the ship-by date a first-class field in the ERP and the warehouse.

Which of the two to use is mostly a cost decision made product by product; see how to compare FBA and FBM cost per order.

Walmart Marketplace: acknowledge, then ship

Documented: Walmart Marketplace APIs authenticate with an access token obtained through the OAuth client credentials grant. Walmart enforces rate limits with a token bucket and reports remaining capacity in the x-current-token-count response header. Orders are acknowledged with a call to the acknowledge endpoint for the purchase order; Walmart’s documentation notes you can re-acknowledge an order already in Acknowledged status (for example after an error) but shouldn’t acknowledge orders that have moved further along. Shipment confirmation with tracking is sent per order line.

Recommendation:

1. Pull or receive new orders, upsert them into the ERP by purchase order ID, then acknowledge only after the ERP has stored the order — acknowledgment is your promise to fulfill.
2. Ship confirmation goes per line with carrier and tracking, after the warehouse confirms the shipment.
3. Read x-current-token-count and slow down before you hit zero instead of waiting for errors.
4. Refresh access tokens before they expire, in one place, so parallel workers don’t race each other.

Inventory across channels

Recommendation: keep a single available-to-sell pool in the ERP and publish per-channel quantities from it:

• Subtract unshipped orders from every channel before publishing.
• Apply per-channel buffers — marketplaces often penalize cancellations for stockouts more than your own store does.
• Exclude FBA stock from what you publish to Shopify and Walmart unless you use Amazon’s multi-channel fulfillment for those orders.
• Push changes on events and reconcile daily. See syncing inventory.

Sales tax and settlements

Documented: states with marketplace facilitator laws require marketplaces that meet thresholds to collect and remit sales tax on the sales they facilitate.

Recommendation:

• Record marketplace-collected tax as collected and remitted by the marketplace, not as your liability, and keep it out of the returns you file yourself. See sales tax in ERP integrations.
• Reconcile settlements, not orders. Each payout nets sales against referral fees, fulfillment fees, refunds, advertising, and adjustments over a settlement period. Import settlement data, book each fee type to its own account, clear the order receivables, and match the net to the bank deposit. Trying to match payouts to individual orders by hand doesn’t scale past a few dozen orders a day.

When a 3PL or EDI is involved

If a 3PL ships your merchant-fulfilled orders, the marketplace adapters still create orders in the ERP, and the ERP sends them to the 3PL — usually via EDI 940/945 or the 3PL’s API. Keep one path to the warehouse. See EDI for ecommerce and 3PLs.

Common pitfalls

• Polling Amazon for orders and hitting the search limit during peak days.
• Acknowledging Walmart orders before the ERP has them, then losing them on an error.
• FBA stock counted as sellable on other channels.
• Marketplace tax reported as your own, or missed in nexus tracking where states count it.
• Payouts matched to orders by hand instead of settlement-level reconciliation.
• Buyer PII copied everywhere after one RDT call.