Walmart Marketplace is the third party seller platform on walmart.com, plus the parallel marketplaces Walmart runs in Canada, Mexico and Chile. For a seller database it is the second most important US channel after Amazon, and unlike Amazon it exposes a single flat REST surface with no separate reports queue for the day to day objects: orders, items, inventory, price and returns are all direct JSON calls. Bulk work goes through the Feeds API, which is asynchronous and reports back per item. Everything below is the US Marketplace API (marketplace.walmartapis.com), which is the surface a US seller integration is built on. Walmart also publishes separate API sets for Walmart Fulfillment Services, Drop Ship Vendors, Walmart Luminate and the international marketplaces; those share the same token model but not the same paths.
At a glance
What it is
Walmart Inc. opened walmart.com to third party sellers in 2009 and moved from an invitation only model to an application based one in 2020. Sellers are US registered businesses with a US tax identifier and a verified fulfilment address, or approved cross border sellers. There is no monthly subscription; Walmart charges a referral fee per category, typically between 6 and 15 percent, and optional Walmart Fulfillment Services fees if the seller stores stock in Walmart's own fulfilment centres.
The marketplace is catalogue based in the same way Amazon is: sellers list offers against an item identified by a Walmart Product ID, the wpid, and matched on GTIN or UPC. A seller supplies its own sku, and every API call is addressed by that seller sku rather than by the Walmart identifier, which is a useful difference from Amazon where most calls key on ASIN. Where more than one seller offers the same item they compete for the Buy Box, which is why Walmart ships a first party repricer that is itself driven through the API.
For an Indian brand, Walmart matters in two ways. It is the natural second US marketplace after Amazon for a brand already exporting, and it is owned by the same group as Flipkart and PhonePe, although the seller systems share nothing operationally. Walmart also runs Walmart Marketplace Mexico and Canada with their own developer portals and their own seller accounts; a brand selling in two of them is two connections in our database.
API access
- The seller signs in to Walmart Seller Center and opens Settings, then API Key Management, or goes to the Developer Portal directly and signs in with the Seller Center account.
- The seller generates a Client ID and Client Secret. These are per seller account, not per user, and can be rotated from the same screen. Losing them means every stored integration for that seller must be re-keyed.
- For a solution provider that wants one app serving many sellers, the route is the Walmart Solution Provider Network. An approved provider gets a single Client ID plus a
WM_PARTNER.ID, and each seller authorises it through the App Store style consent flow, which returns an authorization code that is exchanged for a seller scoped access token and a refresh token.
There is one API version in force for Marketplace, v3, and it has been stable for years. Walmart versions behaviour through feed specification versions instead, for example the MP_ITEM specification which is currently in the 5.x range, and through reportVersion query parameters on the report endpoints. Item specification upgrades are announced with a cut off date after which the old specification version is rejected by the Feeds API; that is the deprecation surface to watch, not the path version.
Base URLs: production is https://marketplace.walmartapis.com, sandbox is https://sandbox.walmartapis.com, or the production host with the WM_SANDBOX: v2 header. Walmart does not publish a first party client library for the Marketplace API in the way Amazon or Shopify do. The portal ships a Postman collection and an OpenAPI definition per API group, and there are third party libraries in Node, Python, PHP and .NET of varying freshness. Plan to generate a client from the OpenAPI definition rather than depending on a community package.
The developer portal is a JavaScript application. Automated fetchers, including ours on 2026-09-21, receive only one operation per API group rather than the full reference. Download the OpenAPI definition or the Postman collection from the portal while signed in rather than scraping the reference pages.
Authentication
Every Marketplace call carries an access token in a Walmart specific header, not in Authorization. Authorization is used only on the token call itself.
Common headers
Getting a token, client credentials grant
This is the path for a seller's own keys.
curl -X POST "https://marketplace.walmartapis.com/v3/token" \ -H "Authorization: Basic $(printf '%s' "$CLIENT_ID:$CLIENT_SECRET" | base64)" \ -H "Accept: application/json" \ -H "Content-Type: application/x-www-form-urlencoded" \ -H "WM_SVC.NAME: Walmart Marketplace" \ -H "WM_QOS.CORRELATION_ID: 0f4c1b4a-2e0f-4a4a-9e2a-9a9a9a9a9a9a" \ -d "grant_type=client_credentials"
{
"access_token": "eyJraWQiOiIzN2JmOWQ5MS04ZDRkLTQwYjEtODU4NS1mNzhlZDc3MjM4MDQiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiZGlyIn0...",
"token_type": "Bearer",
"expires_in": 900
}
The access token is valid for 900 seconds, that is 15 minutes, confirmed on the portal on 2026-09-21. There is no long lived credential in this grant: the Client ID and Client Secret are the durable secret and the token is minted on demand. A practical connector mints one token per seller per run and refreshes when fewer than 120 seconds remain, rather than caching across runs.
Getting a token, authorization code grant
This is the path for a solution provider. The seller is sent to Walmart's consent screen, approves the app, and Walmart redirects back with a code. The code is exchanged at the same /v3/token path with grant_type=authorization_code, code, and the WM_PARTNER.ID header. The response adds a refresh token:
{
"access_token": "eyJraWQiOiIzN2JmOWQ5MS04ZDRkLTQwYjEtODU4NS1mNzhlZDc3MjM4MDQi...",
"token_type": "Bearer",
"expires_in": 900,
"refresh_token": "APXcIoTpKMH9OQN..."
}
The refresh token is valid for 31,536,000 seconds, that is one year. Store it per seller, exchange it with grant_type=refresh_token when the access token expires, and persist any rotated refresh token that comes back. A year long refresh token means the credential store needs a re-consent alert well before expiry, not a retry loop at expiry.
An authenticated call
curl -X GET "https://marketplace.walmartapis.com/v3/inventory?sku=97964_KFTest" \ -H "WM_SEC.ACCESS_TOKEN: $ACCESS_TOKEN" \ -H "WM_QOS.CORRELATION_ID: 0f4c1b4a-2e0f-4a4a-9e2a-9a9a9a9a9a9a" \ -H "WM_SVC.NAME: Walmart Marketplace" \ -H "Accept: application/json"
Multi account
A Client ID and Secret belong to one seller account. Multiple sellers means multiple credential rows, each minting its own token. Under the partner grant one app credential serves many sellers, and the seller is identified by which refresh token is used, not by a parameter on the call. There is no account switching header.
Objects we can read
Orders
The shipping operation was read directly from the reference on 2026-09-21 and is described there as marking order lines shipped, capturing the customer's payment and recording carrier tracking details. The other paths are long standing and stable but were not rendered to the fetcher; treat them as medium confidence and confirm against the downloaded OpenAPI definition.
Key query parameters on GET /v3/orders: sku, customerOrderId, purchaseOrderId, status, createdStartDate, createdEndDate, fromExpectedShipDate, toExpectedShipDate, lastModifiedStartDate, lastModifiedEndDate, limit, productInfo, shipNodeType, replacementInfo, orderType and nextCursor. A date filter is effectively mandatory: createdStartDate in ISO 8601 or plain YYYY-MM-DD form anchors the window. For an incremental sync use lastModifiedStartDate rather than createdStartDate, otherwise status changes on older orders are never picked up.
Pagination is cursor based and unusual: meta.nextCursor is not an opaque token but a ready made query string, including the original filters. Append it to the base path verbatim rather than parsing it.
{
"list": {
"meta": {
"totalCount": 1,
"limit": 1,
"nextCursor": "?limit=1&hasMoreElements=true&soIndex=1234&poIndex=5678&partnerId=10000001&createdStartDate=2026-09-01T00%3A00%3A00.000Z"
},
"elements": {
"order": [
{
"purchaseOrderId": "1796277083022",
"customerOrderId": "5281956426648",
"customerEmailId": "3A31739D8B0A4AAB@relay.walmart.com",
"orderType": "REGULAR",
"orderDate": 1758240000000,
"shippingInfo": {
"phone": "3155554444",
"estimatedDeliveryDate": 1758758400000,
"estimatedShipDate": 1758326400000,
"methodCode": "Value",
"postalAddress": {
"name": "Jane Doe",
"address1": "123 Main St",
"city": "Huntsville",
"state": "AL",
"postalCode": "35805",
"country": "USA",
"addressType": "RESIDENTIAL"
}
},
"orderLines": {
"orderLine": [
{
"lineNumber": "1",
"item": { "productName": "Example Saucepan 2 Quart", "sku": "SKU-001" },
"charges": {
"charge": [
{
"chargeType": "PRODUCT",
"chargeName": "ItemPrice",
"chargeAmount": { "currency": "USD", "amount": 19.99 },
"tax": {
"taxName": "Tax1",
"taxAmount": { "currency": "USD", "amount": 1.6 }
}
},
{
"chargeType": "PRODUCT",
"chargeName": "Shipping",
"chargeAmount": { "currency": "USD", "amount": 0 }
}
]
},
"orderLineQuantity": { "unitOfMeasurement": "EACH", "amount": "1" },
"statusDate": 1758240600000,
"orderLineStatuses": {
"orderLineStatus": [
{
"status": "Acknowledged",
"statusQuantity": { "unitOfMeasurement": "EACH", "amount": "1" }
}
]
},
"fulfillment": {
"fulfillmentOption": "S2H",
"shipMethod": "VALUE",
"shipNodeType": "SellerFulfilled",
"pickUpDateTime": 1758758400000
}
}
]
}
}
]
}
}
}
Points that matter for the loader:
- Every timestamp in the order object is epoch milliseconds, not ISO 8601. The query parameters, confusingly, are ISO 8601.
customerEmailIdis a Walmart relay address, not the shopper's real address. Treat it as PII anyway, since it is a durable per customer identifier. The postal address is real, unmasked PII.- There is no order level total. The total is the sum of
charges.charge[].chargeAmount.amountplus theirtax.taxAmount.amountacross all lines. Walmart models item price, shipping and any fee as sibling charges on the line. - Status lives on the line, not the order, and a single line can be split across several
orderLineStatusentries when a partial quantity ships. The documented values seen in the reference includeCreated,Acknowledged,ShippedandCancelled. shipNodeTypedistinguishesSellerFulfilled,WFSFulfilledand third party fulfilment, which is what drives ourfulfilment_type.
Order items
There is no separate order item endpoint. orderLines.orderLine[] inside the order response is the item level record, keyed by lineNumber within the purchaseOrderId. Note the double nesting, orderLines.orderLine and charges.charge and orderLineStatuses.orderLineStatus, which is a legacy of the XML schema the JSON was generated from. Every array in this API is wrapped in a singular named property.
Products and listings
POST /v3/items/spec was read directly on 2026-09-21. It takes feedType (values seen include MP_WFS_ITEM and MP_VIRTUAL_PACK_BUNDLE), version, and productTypes with a limit of 20 product types per request, and the reference states verbatim that it "is throttled at a maximum of three transactions per minute (TPM) per seller". That endpoint is how a connector discovers the required and optional attributes for a category before building an item feed.
GET /v3/items takes nextCursor, limit, offset, sku, lifecycleStatus, publishedStatus and variantGroupId. Cursor pagination is the supported route past the first few thousand items; offset is capped.
{
"ItemResponse": [
{
"mart": "WALMART_US",
"sku": "SKU-001",
"wpid": "0RCPEXAMPLE1",
"upc": "018111119993",
"gtin": "00018111119993",
"productName": "Example Stainless Saucepan 2 Quart",
"shelf": "[\"Home Page\",\"Home\",\"Kitchen & Dining\",\"Cookware\"]",
"productType": "Cookware",
"price": { "currency": "USD", "amount": 19.99 },
"publishedStatus": "PUBLISHED",
"lifecycleStatus": "ACTIVE",
"variantGroupId": "GRP-SAUCEPAN",
"variantGroupInfo": { "isPrimary": "true", "groupingAttributes": ["capacity"] }
}
],
"totalItems": 1,
"nextCursor": "AoE/..."
}
publishedStatus carries values in the family PUBLISHED, UNPUBLISHED, IN_PROGRESS, STAGE, READY_TO_PUBLISH and SYSTEM_PROBLEM, with an unpublishedReasons array explaining why an item is not live. lifecycleStatus separates ACTIVE, ARCHIVED and RETIRED. Both are needed: an item can be lifecycle active and still unpublished because of a content or compliance block, and only the pair tells us whether the listing is actually buyable. This is the field mapping that decides our listings.status. Confidence on the exact enumerations is medium; confirm against the OpenAPI definition. The item response does not include the listing URL, so build it from the wpid as https://www.walmart.com/ip/{wpid}.
Inventory
Read: GET /v3/inventory?sku={sku} with an optional shipNode. Read directly from the reference on 2026-09-21, so this one is high confidence.
{
"sku": "97964_KFTest",
"quantity": { "unit": "EACH", "amount": 10 },
"inventoryAvailableDate": "2024-09-12"
}
quantity.unit only supports EACH. inventoryAvailableDate is the date the stock is expected at the ship node, which is how Walmart models inbound supply rather than a separate inbound quantity field. There is no reserved quantity in this response, so our inventory.quantity_reserved is not populated from Walmart. For a seller with more than one ship node the per node figure requires the shipNode parameter, and there is a multi node variant of the endpoint for setting all nodes in one call. Walmart Fulfillment Services stock is reported separately from seller fulfilled stock and cannot be written by the seller at all.
A full inventory read is one call per SKU, which is the single worst scaling property of this API. For anything past a few hundred SKUs, pull the inventory report from the Reports API on a schedule and use GET /v3/inventory only for spot checks.
Shipments and tracking
There is no shipments collection. Tracking is written by us with POST /v3/orders/{purchaseOrderId}/shipping and read back inside orderLineStatuses.orderLineStatus[].trackingInfo:
{
"trackingInfo": {
"shipDateTime": 1758326400000,
"carrierName": { "carrier": "UPS" },
"methodCode": "Standard",
"trackingNumber": "1Z97Y4430300463366",
"trackingURL": "https://www.ups.com/track?tracknum=1Z97Y4430300463366"
}
}
The carrierName object takes either carrier from Walmart's enumerated carrier list, for example UPS, FedEx or USPS, or otherCarrier with free text when the carrier is not on the list. There are no carrier scan events in this API, and delivery status comes back only as the order line moving to a delivered state, so per event tracking has to come from the carrier connector.
Returns and cancellations
The refund operation was read directly on 2026-09-21. returnOrderId is described in the reference as the return order identifier, also known as the RMA number. Its request body is small:
{
"customerOrderId": "1535274411287",
"refundLines": [
{ "returnOrderLineNumber": 1, "quantity": { "unitOfMeasure": "EA", "measurementValue": 2 } }
]
}
Note the inconsistency with the rest of the API: returns use unitOfMeasure and measurementValue where orders and inventory use unitOfMeasurement and amount, and EA where inventory uses EACH. A shared quantity parser will break here.
GET /v3/returns filters on returnOrderId, customerOrderId, purchaseOrderId, status, returnType, replacementInfo, createdStartDate, createdEndDate, limit and offset, and returns returnOrders[] each with returnLines[] carrying the item, the return reason, the charges to refund and a per line status. Confidence medium: the collection endpoint did not render to the fetcher.
Cancellations by the seller go through POST /v3/orders/{purchaseOrderId}/cancel. Customer cancellations arrive as an order line status of Cancelled with a cancellationReason, not as a return.
Payments and settlements
Walmart pays sellers biweekly and exposes the detail as downloadable report files rather than as a queryable API.
GET /v3/report/reconreport/availableReconFiles?reportVersion=v1lists the report dates that exist for the seller.GET /v3/report/reconreport/reconFile?reportDate=09/15/2026&reportVersion=v1streams the file for one of those dates.
The response to the second call is a compressed CSV, not JSON, so the connector needs a download and unzip step rather than a JSON parser. The report is line level: each row carries the purchase order, the order line, the transaction type (sale, refund, adjustment, WFS fee, commission), the gross amount and the fee amounts, which is exactly the grain our settlements table wants. reportDate uses MM/DD/YYYY, which does not match any other date format in this API.
Confidence medium: these paths are long established but were not rendered to the fetcher on 2026-09-21. There is also a newer asynchronous Reports API in the shape of a request, poll, download cycle covering item, inventory, buybox and cancellation reports; verify the exact request paths from the portal before building against it.
Customers
No customer endpoint. What exists is the per order customerEmailId relay address, shippingInfo.postalAddress and shippingInfo.phone. There is no customer identifier that is stable across orders, so customers.customer_id has to be synthesised, and the relay email is the only candidate key. Walmart deliberately does not give sellers a customer list.
Locations
Ship nodes are the location concept. They are configured in Seller Center, referenced by shipNode on inventory calls and by shipNodeType on order lines. Confidence low on whether there is a public endpoint that enumerates a seller's ship nodes; the portal did not render one. Practical approach: collect the distinct shipNode values seen on inventory and order responses, and ask the seller to confirm the list at onboarding.
Writing back: listings, price and stock
Price, single item
PUT /v3/price
Host: marketplace.walmartapis.com
WM_SEC.ACCESS_TOKEN: {token}
WM_QOS.CORRELATION_ID: {guid}
WM_SVC.NAME: Walmart Marketplace
Content-Type: application/json
Accept: application/json
{
"sku": "SKU-001",
"pricing": [
{ "currentPriceType": "BASE", "currentPrice": { "currency": "USD", "amount": 17.99 } }
]
}
The response is synchronous and confirms the SKU and the new price, so a price write needs no polling. Promotional and strikethrough pricing is a separate mechanism: the PROMO_PRICE feed type, confirmed in the feed type list on 2026-09-21, which carries the promotional price, the comparison price and an effective and expiration window.
Price, batch
Two feed types cover batch price work, both confirmed on the reference on 2026-09-21: MP_ITEM_PRICE_UPDATE for base price changes and PROMO_PRICE for promotions. Batch price is the right route above roughly a few dozen SKUs, since single calls are throttled per seller.
Repricer
Walmart is unusual in exposing its own Buy Box repricer through the API. PUT /v3/repricer/strategy/{strategyCollectionId} was read directly on 2026-09-21 and updates a named strategy:
{
"repricerStrategy": "Buy Box Strategy",
"strategyCollectionId": "41678999-a088-4fd8-9eb4-55f8d8ed4ac8",
"enabled": true,
"enableRepricerForPromotion": true,
"restoreSellerPriceWithoutTarget": true,
"enableBuyboxMeetExternal": true,
"compareWith3pOfferOnly": true,
"strategies": [
{ "strategyType": "Buy Box Price", "adjustmentType": "UNIT", "adjustmentValue": 1.2 }
]
}
If a seller has the Walmart repricer enabled, our price writes are not the final word. Walmart will move the live price inside the strategy's bounds after we write, and a naive reconciliation job will read back a price it did not set and try to correct it forever. Read enabled on the strategy before treating a price mismatch as a sync failure.
Stock
Single item: PUT /v3/inventory?sku={sku} with the same shape the GET returns.
{ "sku": "SKU-001", "quantity": { "unit": "EACH", "amount": 25 } }
Batch: the inventory feed type, confirmed on the reference. There is also a multi node inventory write for sellers shipping from several nodes, which takes a nodes array of ship node and quantity pairs. Confidence medium on the exact multi node path. LAGTIME, also confirmed as a feed type, sets the fulfilment lag in days per SKU. It is separate from quantity and is what actually drives the promised delivery date shown to the shopper, so a stock connector that ignores it will produce accurate quantities and wrong delivery promises.
Listing content
Item creation and content updates are feed only. POST /v3/feeds?feedType=item uploads a JSON or XML document built against the specification returned by POST /v3/items/spec for the relevant product type. The upload is multipart/form-data with the document as the file part, and the response is a feed identifier:
{ "feedId": "F129C3E52B5E47E19EFCA84D4BC1C11A@AQMBAQA" }
Confirming a feed
GET /v3/feeds returns feed statuses. Read directly on 2026-09-21:
{
"totalResults": 115,
"offset": 0,
"limit": 50,
"results": {
"feed": [
{
"feedId": "882DAFBDCAA0480786D1E0435FBC86D7@AU8BAgA",
"feedSource": "MARKETPLACE_PARTNER",
"feedType": "item",
"partnerId": "100009",
"itemsReceived": 1,
"itemsSucceeded": 1,
"itemsFailed": 0,
"itemsProcessing": 0,
"feedStatus": "PROCESSED"
}
]
}
}
The four statuses, quoted from the reference, are RECEIVED (submitted and awaiting processing), INPROGRESS (currently being processed), PROCESSED (completed) and ERROR (a critical error). Confirmed feed type values on the same page: item, inventory, LAGTIME, PROMO_PRICE, MP_ITEM_PRICE_UPDATE and CPT_SELLER_ELIGIBILITY. The portal documents more elsewhere, including Walmart Fulfillment Services item feeds and shipping override feeds.
PROCESSED does not mean every item succeeded. Compare itemsSucceeded against itemsReceived and, when they differ, request the same feed identifier with the detail flag to get a per item ingestion status carrying the SKU, the status and the error list. A write connector must store the feed identifier against the batch and poll it, because a silently half applied feed is the most common failure mode on this platform.
Webhooks and notifications
Walmart's Notifications API lives at /v3/webhooks. POST /v3/webhooks/test was read directly on 2026-09-21 and its request body shows the subscription shape:
{
"eventType": "OFFER_UNPUBLISHED",
"eventVersion": "V1",
"resourceName": "ITEM",
"eventUrl": "https://connectors.example.com/walmart/events",
"authDetails": {
"authMethod": "BASIC_AUTH",
"userName": "abc",
"password": "test",
"authHeaderName": "Authorization"
},
"headers": {
"X-Custom-Header": "my-value"
}
}
The pieces that matter:
- A subscription is a triple of
resourceName(a functional grouping such asITEM),eventTypeandeventVersion, plus the destinationeventUrl. - Delivery authentication is our choice, not Walmart's.
authMethodacceptsBASIC_AUTH,OAUTHandHMAC. ChooseHMACso the receiver can verify the body rather than trusting a static credential in a header. - Custom headers can be attached per subscription, which is a clean way to route by seller on a shared receiver endpoint.
POST /v3/webhooks/testsends a sample event to the destination, which makes receiver development testable without waiting for a real order.
Confirmed event type seen in the reference: OFFER_UNPUBLISHED. The full event catalogue did not render to the fetcher, so confidence on the list is low. The families that exist cover item setup and publish state, purchase order creation, order cancellation, return creation, price change and inventory change. Enumerate the real list from the event types endpoint on the portal before designing the subscription set.
Because the event catalogue is unverified, design the connector to poll and treat notifications as an accelerator. Poll GET /v3/orders on lastModifiedStartDate every 10 minutes, GET /v3/orders/released every 5 minutes during business hours, GET /v3/returns hourly, items and the inventory report nightly, and the available reconciliation file list daily.
Rate limits and pagination
Walmart publishes a per API throttle table in the portal, expressed in transactions per minute per seller. That table did not render to our fetcher on 2026-09-21, and the only figure read verbatim was for POST /v3/items/spec: "throttled at a maximum of three transactions per minute (TPM) per seller". Do not guess the rest. Pull the table from the portal at build time and drive the connector's limiter from it rather than from hard coded constants.
What can be said with confidence: throttling is per seller rather than per app, so a solution provider's aggregate throughput scales with the number of connected sellers. Limits differ sharply by API, with the specification and feed submission endpoints measured in single digit transactions per minute while the order read endpoints are far more generous. Exceeding a limit returns HTTP 429, so back off exponentially with jitter and never retry a write immediately, because a feed submitted twice is two batches. The 15 minute token lifetime is itself a rate consideration: minting a token per call will hit the token endpoint's own limit.
Pagination models in this API are not consistent, which is the main trap:
Practical cadence for a seller with a few thousand SKUs: orders every 10 minutes on lastModifiedStartDate, returns hourly, items and the inventory report nightly, reconciliation files daily. Price and stock writes batched into feeds rather than single calls, submitted on a fixed schedule, with feed identifiers polled until terminal.
Mapping to the unified model
orders
order_items
listings
inventory
shipments
returns and settlements
Gaps and open questions
- The full published rate limit table could not be read. Only the three transactions per minute figure for the item specification endpoint is verified. This must be pulled from the portal before the connector's limiter is written.
- The webhook event type catalogue could not be enumerated. Only
OFFER_UNPUBLISHEDis confirmed. Whether a reliable order created event exists, and whether it is delivered at least once or at most once, is unverified, so the first version should poll. The signature scheme underauthMethod: HMACis also undocumented in what we could read: which header carries the signature, what is signed and how the secret is established are all unknown. - There is a newer asynchronous Reports API alongside the older reconciliation file endpoints. Which one is current for settlement data, and whether the older recon paths have a deprecation date, is unresolved.
- Whether a public endpoint enumerates a seller's ship nodes is unverified, and the multi node inventory write path and its exact request body are medium confidence.
- Walmart Fulfillment Services adds its own item feed types, inbound shipment endpoints and fee reporting that are out of scope here and need a separate pass if any connected seller uses WFS. Walmart Canada and Mexico use the same token model and similar paths but different hosts and different item specifications; do not assume the US connector works against them without testing.
Sources
- Walmart Marketplace Token API reference, read 2026-09-21:
/v3/token, grant types, headers, 900 second access token, one year refresh token - Walmart Marketplace Inventory API reference, read 2026-09-21:
GET /v3/inventory, sample response, header set - Walmart Marketplace Orders API reference, read 2026-09-21:
POST /v3/orders/{purchaseOrderId}/shipping, order and order line schema - Walmart Marketplace Items API reference, read 2026-09-21:
POST /v3/items/spec, 20 product type limit, three transactions per minute throttle - Walmart Marketplace Price API reference, read 2026-09-21:
PUT /v3/repricer/strategy/{strategyCollectionId}and its strategy object - Walmart Marketplace Feeds API reference, read 2026-09-21:
GET /v3/feeds, feed type list, four feed statuses, sample response - Walmart Marketplace Returns API reference, read 2026-09-21:
POST /v3/returns/{returnOrderId}/refundand its request and response bodies - Walmart Marketplace Notifications API reference, read 2026-09-21:
POST /v3/webhooks/test, subscription fields, authentication methods - Introduction to Marketplace APIs, read 2026-09-21: OAuth 2.0, 15 minute token, Dynamic Sandbox
- Walmart Marketplace authentication guide, read 2026-09-21