Checking dispute status

Use the Dispute status API to check the processing status of duplicate item disputes you previously submitted. You send a list of product identifiers, and the service returns a per-item status indicating where each dispute is in the workflow.

• You submit productId and productIdType pairs under issues.
• The service looks up each dispute and returns an itemResponse array.
• Each entry includes the current status and a lastUpdatedDate (Unix epoch timestamp).
• Typical statuses include: IN_REVIEW, PROCESSING, ERROR, COMPLETED.

Endpoint

POST https://marketplace.walmartapis.com/v3/items/dispute/duplicates/status

Sample request

curl -X 'POST' '<http://marketplace.walmartapis.com/v3/items/dispute/duplicates/status'> -H 'accept: application/json' -H 'WM_SEC.ACCESS_TOKEN: eyJraWQiOiIzZjVhYTFmNS1hYWE5LTQzM.....' -H 'WM_QOS.CORRELATION_ID: b3261d2d-028a-4ef7-8602-633c23200af6' -H 'WM_SVC.NAME: Walmart Service Name' -H 'Content-Type: application/json' -d '{ "issues": [ { "productId": "string", "productIdType": "string" } ] }'

import requests url = "http://marketplace.walmartapis.com/v3/items/dispute/duplicates/status"
headers = { "accept": "application/json", "WM_SEC.ACCESS_TOKEN": "eyJraWQiOiIzZjVhYTFmNS1hYWE5LTQzM.....", "WM_QOS.CORRELATION_ID": "b3261d2d-028a-4ef7-8602-633c23200af6", "WM_SVC.NAME": "Walmart Service Name", "Content-Type": "application/json"
}
data = { "issues": [ { "productId": "string", "productIdType": "string" } ]
} response = requests.post(url, headers=headers, json=data)
print(response.status_code)
print(response.json())

Modify the code

Follow these steps to customize the sample and get a successful response:

1. Replace the access token and other placeholder header values with your actual data.
2. Populate the request body with real IDs:

• productId: Provide a valid identifier for the disputed item (for example, a WPID value).
• productIdType: Use the correct type for the productId you send (for example, WPID). Keep types consistent across entries.

3. Add multiple objects under issues to check several disputes in one call.
4. Handle response statuses:

• Treat COMPLETED as final.
• IN_REVIEW or PROCESSING indicates the dispute is still underway; you can poll again later.
• If ERROR, contact Support.

5. Resilience and safe logging: On 429 or 5xx, retry with exponential backoff and random jitter. Log only non-sensitive metadata (timestamp, path, status, attempt); never log tokens.

Sample response

{ "itemResponse": [ { "productId": "3V47ZGPR09H5", "productIdType": "WPID", "status": "IN_REVIEW", "lastUpdatedDate": "<TIMESTAMP: Unix Epoch timestamp>" }, { "productId": "12G6TANIZ4WR", "productIdType": "WPID", "status": "PROCESSING", "lastUpdatedDate": "<TIMESTAMP: Unix Epoch timestamp>" }, { "productId": "9JX7AGCLSR8H", "productIdType": "WPID", "status": "ERROR", "lastUpdatedDate": "<TIMESTAMP: Unix Epoch timestamp>" }, { "productId": "12G6TANIZ4WR", "productIdType": "WPID", "status": "COMPLETED", "lastUpdatedDate": "<TIMESTAMP: Unix Epoch timestamp>" } ] }

Next steps

• Build a polling strategy for IN_REVIEW/PROCESSING items with exponential backoff and jitter.
• Surface ERROR entries to Support with the identifiers used so they can correct input or escalate.
• Once COMPLETED, proceed with any downstream catalog updates your workflow requires.