Archive Catalog
- Archive Catalog
- Body parameter
- Example responses
- Response payload examples
- Recommended integration workflow
The Archive Catalog API allows you to programmatically archive (deactivate) products that are no longer available for sale across all your stores. Archived products are removed from the active catalog but their data is retained in the system.
Archive Catalog
POST /v1/catalog/archive
This method marks products as inactive (ARCHIVED) across all applicable stores for a retailer. The operation is processed asynchronously — the API returns an ingestionId that you can use with the GetUploadStatus API to track progress.
Important notes
- Archiving affects all stores for your retailer — you cannot archive a SKU in one store only
- SKU-level errors (e.g., SKU still on planogram, already archived) are returned asynchronously in the processing report, not in the API response
- Archived items are deactivated from active inventory but transaction history is preserved
- You can reactivate archived items by uploading them again using the standard Upload Catalog API
Archive Limits
- Maximum SKUs per request: 10,000 SKUs
- If you need to archive more than 10,000 SKUs, split your request into multiple API calls
Body parameter
{
"itemSkus": ["string"],
"allApplicableStores": ["string"]
}
| Data Field | Required | Description |
|---|---|---|
| itemSkus | Required | Array of item SKU strings to archive. Each SKU must match an existing active product in your catalog. |
| allApplicableStores | Required | Array of all external store IDs for your retailer. You must provide the complete list of stores associated with your retailer account. This confirms you understand the archive affects all stores. |
allApplicableStores field must contain every store ID for your retailer — not just the stores where the SKU is sold. If any stores are missing, the API will return an error listing all available stores.Example responses
| Status | Meaning | Description |
|---|---|---|
| 201 | Created | Unique ID for tracking the archive operation. Use this with the GetUploadStatus API to check progress. |
| 400 | Bad Request | Validation error — missing stores, invalid store IDs, or cross-merchant stores. |
| 429 | Too Many Requests | API rate limit exceeded. Retry after a brief delay. |
| 500 | Internal Server Error | Internal error during processing. |
Response payload examples
| Status code | Message | Meaning |
|---|---|---|
| 201 |
|
Archive request accepted. Use the ingestionId with the GetUploadStatus API to track progress and download the processing report. |
| 400 |
|
Partial store list — you provided some valid stores but not all stores for your retailer. The error message lists all available stores. |
| 400 |
|
Store IDs belong to different retailers. All stores in the request must belong to the same retailer. |
| 400 |
|
All provided store IDs are invalid or not found in the system. |
| 400 |
|
Invalid request format or SKU list exceeds the 10,000 limit. |
| 500 |
|
Internal store configuration issue. Contact Amazon support to resolve. |
| 500 |
|
Unknown error — retry is recommended. |
| 429 |
|
API rate limit exceeded. |
Recommended integration workflow
When archiving SKUs from your POS system, do not delete them from your system immediately. Follow this workflow:
- Call Archive API — Send
POST /v1/catalog/archivewith the SKUs and your complete store list - Receive ingestion ID — The API returns immediately with an
ingestionId - Poll for status — Call the GetUploadStatus API with the
ingestionId, or wait for an SQS notification - Download report — Retrieve the processing report from the S3 URL in the response
- Check status — Verify all SKUs show
SUCCESSin the report - Delete from POS — Only after
SUCCESSconfirmation, remove the SKU from your POS system

