Short answer
The Walmart Marketplace API is a REST API that lets a seller, or software acting for sellers, create and update items, manage prices and inventory, receive and fulfil orders, and subscribe to order events. You authenticate with OAuth 2.0 and send a 15-minute access token on every call. The parts that decide whether an integration works in production are the four-hour order acknowledgement window, the asynchronous item feeds and the per-endpoint rate limits. Two changes are close: Walmart's legacy order webhooks are deprecated on 15 December 2026, and Delegated Access keys stop working after 30 April 2027.
Everything below was checked against Walmart's developer documentation on 28 October 2026. Walmart revises these pages often, so treat the numbers as a snapshot and read the current page before you rely on one.
What the Walmart API covers
Walmart publishes separate Marketplace API documentation for the US, Canada, Mexico and Chile marketplaces. The US set is the largest. Within it, the API groups a seller works with day to day are:
- Items: item setup and maintenance, mostly through bulk feeds, plus item and catalog search.
- Prices and promotions: single price updates and bulk price feeds.
- Inventory: quantities per SKU, per ship node, or for many items at once.
- Orders: listing, acknowledging, shipping, cancelling and refunding order lines.
- Walmart Fulfillment Services (WFS): items and inventory that Walmart fulfils for you.
- Notifications: webhook subscriptions for order and other events.
Production calls go to https://marketplace.walmartapis.com, sandbox calls to https://sandbox.walmartapis.com. One thing to settle early: if you sell to Walmart as a supplier rather than on the marketplace, you are on a different documentation set, the supplier APIs. This guide is about the Marketplace, where you are the seller of record.
Authentication and API keys
There are two ways in, and the choice shapes the whole integration.
Your own seller account. A seller takes a Client ID and Client Secret from the API Keys section of the Walmart developer account and uses the OAuth 2.0 client credentials grant: a POST to /v3/token with Basic authentication built from the ID and secret. The Token API page gives the access token a lifetime of 900 seconds. This flow returns no refresh token, so your code simply asks for a new access token before the old one runs out. Every Marketplace call then carries the token in the WM_SEC.ACCESS_TOKEN header.
Software that serves many sellers. An approved solution provider uses the authorization code flow. The seller opens the App Store in Seller Center, connects your app and authorizes it; your app exchanges the one-time code for an access token and a refresh token. Walmart states that refresh tokens remain valid for a year, so a multi-seller product needs to store one refresh token per seller, encrypted, and to warn the seller well before it lapses.
Delegated Access is on its way out. Sellers used to create separate keys for each solution provider. According to Walmart's authentication page, new Delegated Access keys can no longer be created and existing ones stop working after 30 April 2027. OAuth 2.0 is required for new integrations. If any of your connections still run on delegated keys, put the move on this year's plan, not next year's.
Two errors are worth telling apart in your logs. A 401 means the token is missing, malformed, expired or was issued for the other environment. A 403 means the token is fine but the app lacks permission for that endpoint. Retrying a 403 never helps; fixing the app's scopes does.
Items and feeds
Catalog work on Walmart is asynchronous. You submit a file with POST /v3/feeds?feedType=..., Walmart answers at once with a feedId, and the actual processing happens later. The bulk item setup guide lists the feed types, among them MP_ITEM for new seller-fulfilled items, MP_WFS_ITEM for Walmart-fulfilled items and MP_MAINTENANCE for updates. A single feed may hold up to 10,000 items, and Walmart recommends keeping files under 25 MB.
What this means for the build:
- Store every
feedIdwith the SKUs and the payload it carried, so an item-level error can be traced back to the record that caused it. - Expect partial success. A feed can process most items and reject a few; the integration should resubmit only the rejected SKUs after the data is fixed.
- Do not hammer the error report. Walmart's published default for the feed error report is 60 calls an hour, while feed status checks are allowed at 5,000 a minute. Poll status, then fetch the report once.
Orders: the four-hour clock
Walmart order lines move through Created, Acknowledged, Shipped, Delivered and Canceled. The step that catches new integrations is acknowledgement. Walmart's acknowledgement guide asks sellers to acknowledge new orders within four hours of creation, using POST /v3/orders/{purchaseOrderId}/acknowledge. Orders fulfilled by Walmart are processed automatically and cannot be acknowledged, so your code has to skip them.
Reading orders has its own limits. The get all orders reference returns only orders created in the last 180 days, defaults to the last seven days when you pass no dates, returns at most 200 orders per page and pages with a nextCursor value. A single fetch may not exceed 10,000 orders.
Our usual design: an order event or a short polling cycle creates the order in the seller's own system first, then acknowledges it on Walmart, so an order is never confirmed to the customer before it exists in the warehouse queue. Acknowledgement is safe to repeat (Walmart allows re-acknowledging an order that is already acknowledged), which makes the retry logic simple. Ship confirmations go back with tracking details and a UTC timestamp.
Inventory and prices
Inventory can be updated per SKU, per ship node or for many items at once. Walmart's published default for these endpoints is 200 calls a minute each, which is enough for event-driven updates but not for pushing a full catalog item by item every few minutes.
Prices are tighter. The bulk price feed (feedType=PRICE_AND_PROMOTION) has a default of 10 submissions an hour, shared with several other bulk price endpoints. A repricer that fires a feed for every change will run out within minutes. Collect changes for a short window and send them together.
The harder question is ownership. When Walmart sits next to Amazon, Shopify or an ERP, decide which system owns stock and which owns price, write it down, and make every other system read from that owner. Overselling across channels almost always traces back to two systems that each believe they hold the truth.
Webhooks instead of polling
Walmart can push events to an HTTPS endpoint you register with POST /v3/webhooks/subscriptions. The Event Types API lists what you can subscribe to. On 11 February 2026 Walmart added an ORDER_UPDATES event whose payload carries a sub-event type: PO_CREATED, PO_LINE_AUTOCANCELLED, INTENT_TO_CANCEL or FRAUD_CANCEL. The standalone legacy events PO_CREATED, PO_LINE_AUTOCANCELLED and INTENT_TO_CANCEL are deprecated on 15 December 2026.
If your integration subscribed to the old events, you have about seven weeks from the date of this article. Subscribe to ORDER_UPDATES, route on the sub-event type, and run both side by side for a few days before you remove the old subscription. Keep a slow reconciliation poll running even when webhooks work: a missed event should cost you minutes, not an order.
Rate limits
Walmart uses a token bucket. Limits are set per seller and per API, a seller's direct calls and a solution provider's calls draw from separate allotments, and a provider with several apps gets separate limits for each app. Each response tells you where you stand in two headers, x-current-token-count and X-Next-Replenishment-Time. Exceed the limit and you get 429 Too Many Requests; send a file that is too large and you get 413.
A few of the published defaults from the rate limiting page, which apply to individuals and smaller businesses:
| Operation | Default limit |
|---|---|
| Get all orders | 5,000 per minute |
| Acknowledge, ship, cancel or refund order lines | 60 per minute each |
| Get all items | 300 per minute (60 with query parameters) |
| Update inventory | 200 per minute |
| Feed error report | 60 per hour |
| Bulk price feed | 10 per hour, shared |
The practical answer is one queue per seller and endpoint group that reads the token count from each response and slows down before it hits zero, rather than a fixed sleep between calls. The 60-per-minute limit on order line actions matters most on peak days, when acknowledgements and ship confirmations compete for the same budget.
Sandbox and testing
The sandbox has its own base URL, and Walmart is explicit that tokens and base URLs must come from the same environment; a production token against the sandbox fails with a 401. For the US marketplace, the orders reference also documents a WM_SANDBOX header (value v2) for the dynamic sandbox. Test the paths that hurt in production: an acknowledgement retried after a timeout, a partial shipment, a line cancelled by Walmart while you were packing it, and a feed with one bad item among good ones.
A build plan that holds up
- Pick the account model. Your own keys for one seller, or an OAuth app if you will serve many. Do not start on Delegated Access.
- Map SKUs and item data. Walmart's item specifications differ from Amazon's; mapping attributes is usually the longest part of onboarding a catalog.
- Ship orders first. Import, acknowledge inside four hours, confirm shipment with tracking. This is where revenue and seller metrics live.
- Then inventory and price, with one owner per field and batched price feeds.
- Webhooks plus a reconciliation poll, already on
ORDER_UPDATES. - Monitoring from day one. Alert on orders close to the four-hour mark, feed errors, a rising share of 429 responses and failing token refreshes. Our article on monitoring systems in production covers the tooling.
When to bring in a team
A single-seller order sync is a reasonable in-house project. It gets harder when Walmart has to agree with Amazon, Shopify and an ERP at the same time, when a product will serve many sellers through OAuth, or when deprecations like the two above land on a team that is busy with everything else.
Deltologic has built marketplace integrations since 2020, Walmart among them. You can read about the scope on our marketplace integrations page, see published Walmart projects, or ask us to keep an existing integration current through API migrations and upkeep. If you are planning a Walmart build, send us a short brief: what you sell, where, and which systems Walmart has to talk to. A senior engineer reads it and replies with how we would approach it.
Frequently asked questions
Does Walmart have an API for marketplace sellers?
Yes. The Walmart Marketplace API is a REST API for items, prices, inventory, orders, Walmart Fulfillment Services and webhook notifications, with separate documentation for the US, Canada, Mexico and Chile marketplaces.
How long does a Walmart API access token last?
An access token is valid for 900 seconds (15 minutes) and goes in the WM_SEC.ACCESS_TOKEN header on every call. The client credentials flow returns no refresh token; the authorization code flow used by solution providers returns a refresh token that Walmart says stays valid for a year.
How quickly must Walmart orders be acknowledged?
Walmart asks sellers to acknowledge new orders within four hours of creation. Orders fulfilled by Walmart are processed automatically and cannot be acknowledged.
Is Walmart Delegated Access still supported?
No new Delegated Access keys can be created, and existing keys stop working after 30 April 2027. New integrations must use OAuth 2.0.