Microsoft Dynamics 365 F&O and Walmart Marketplace integration

What moves between them

Three flows run between the systems. Orders move from Walmart Marketplace into Microsoft Dynamics 365 F&O: ml-connector reads released orders and posts them as customer sales against the matching released products and a customer record. Product, inventory, and price data move the other direction, from D365 out to Walmart as bulk feeds so listings, stock, and prices reflect ERP truth. Walmart reconciliation reports move into D365 as general ledger journal lines covering payouts, fees, and refunds, mapped to main accounts and financial dimensions. Walmart has no GL resource, so ml-connector never writes ledger entries back to the marketplace.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the D365 side it requests a Microsoft Entra ID client-credentials token with the host .default scope and refreshes it before the roughly one-hour expiry, accepts the full tenant operations.dynamics.com URL per customer, and sets the right dataAreaId and cross-company flag on each call. On the Walmart side it exchanges Client ID and Secret for a token, replays it in the WM_SEC.ACCESS_TOKEN header with WM_SVC.NAME and a fresh correlation id on every request, and re-authenticates well before the 15-minute window closes. Because Walmart's single-item APIs are throttled, item, inventory, and price writes go out as MP_ITEM, inventory, and price feeds, and ml-connector tracks each feedId until its results confirm. SKUs are mapped to D365 product numbers first, so every Walmart order line resolves to a released product before the sale is posted. D365 has no OData idempotency key, so ml-connector dedupes on the Walmart purchaseOrderId and a BullMQ jobId before writing, which avoids double-booking a re-read order, and Walmart's order state machine makes a repeated acknowledge a no-op. A Walmart ORDER or REPORT webhook can trigger a pull immediately, while a scheduled poll respects the 180-day order window and backfills anything a push missed. Reconciliation journals post through D365 Journal entities, since posted ledger entries are not directly writable. On a 429 from either side ml-connector backs off with jitter and honors Walmart's token-replenishment timing and D365's Retry-After. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods brand, roughly 150 staff, runs Microsoft Dynamics 365 F&O for inventory, fulfillment, and finance, and sells direct to shoppers on a Walmart Marketplace seller account. Before the integration, a coordinator exported Walmart orders to a spreadsheet and keyed them into D365, manually updated Walmart stock and prices when the ERP changed, and at month-end reconciled Walmart payout statements against the ledger line by line. Orders sat for hours, oversells happened when Walmart stock lagged the warehouse, and the marketplace receivables never matched the books. With Microsoft Dynamics 365 F&O and Walmart Marketplace connected, each released order posts as a customer sale within the polling window, inventory and price feeds keep listings current, and every settlement lands in the general ledger allocated to the right accounts. The re-keying is gone and the Walmart payouts reconcile without a manual chase.

What you can do

• •Post Walmart Marketplace orders into Microsoft Dynamics 365 F&O as customer sales against matching released products.
• •Publish D365 product, inventory, and price changes to Walmart Marketplace as throttle-safe bulk feeds.
• •Turn Walmart settlement reports into D365 general ledger journal lines for payouts, fees, and refunds.
• •Bridge the Microsoft Entra ID OAuth2 token and Walmart's 15-minute WM_SEC.ACCESS_TOKEN with its required headers.
• •Dedupe orders on purchaseOrderId and jobId, with retries and a full audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and Walmart Marketplace?

It moves both ways across three flows. Walmart orders come into D365 as customer sales, while product, inventory, and price data go from D365 out to Walmart as bulk feeds. Walmart settlement reports also come into D365 as ledger journals. Walmart has no GL or chart-of-accounts resource, so ml-connector never writes ledger entries back to the marketplace.

How does the integration deal with Walmart's aggressive single-item throttling?

Walmart's single-item sync calls are meant for emergency use and are heavily rate limited, so ml-connector sends item, inventory, and price changes as MP_ITEM, inventory, and price feeds instead. It tracks each feedId and checks the feed results before considering the write done. On a 429 it backs off with jitter and honors the token-replenishment timing Walmart returns.

How are the two different OAuth setups handled on each side?

Both sides use OAuth2 client credentials, but the details differ. For D365 ml-connector requests a Microsoft Entra ID token with the host-scoped .default scope and refreshes it before its one-hour expiry. For Walmart it exchanges the Client ID and Secret, then replays the token in the non-standard WM_SEC.ACCESS_TOKEN header with the mandatory WM_SVC.NAME header on every call, re-authenticating before the 15-minute token expires.