Skip to main content

Get the current catalog manifest snapshot

GET 
/partner/catalog/manifest

Returns metadata for the newest catalog snapshot plus a presigned URL to a gzipped NDJSON manifest of the SKUs that have a row in our market-state store. This is not every priceable SKU — a SKU can be priceable by GET /partner/lowest/{sku} and still be absent here; see caveat 3. Do not use the manifest as your only source of SKUs to price.

The URL is requested with a 1 hour expiry and url_expires_at reports that time, but it is signed with this service's own temporary credentials, so it can stop working earlier if those credentials rotate first. Treat a 403 from the URL as "re-request the manifest", not as an error.

Use this instead of crawling SKU-by-SKU: download the manifest, keep it, then poll GET /partner/catalog/delta?since={snapshot_id} and re-pull the SKUs it reports (via POST /partner/lowest/bulk).

Re-download the manifest periodically — weekly is enough. The kept copy is a point-in-time document and the delta cannot re-baseline it: it says nothing about product metadata (caveat 2), nothing about SKUs that are not in the snapshot (caveat 3), and it only reports price_source transitions for the SKUs it happens to name (caveat 5, now_live).

That loop does not cover the whole manifest. Lines with price_source: "live" are ones we cannot fingerprint, so the delta reports nothing about them and you must refresh them on your own schedule. They are labelled per line and counted in live_priced_sku_count. Read caveat 5 before you treat "not in changed" as "unchanged".

Each manifest line is one JSON object:

{"sku":"AT8086-002","sizes":15,"hash":"1f3a9c...","price_source":"snapshot","updated_at":"2026-07-31T08:12:03.000Z"}

hash is an opaque content fingerprint — compare it for equality only, never parse it. hash may be null; see caveat 5.

Caveats — read these before building against it. Caveats 2, 3 and 5 are real limits of this endpoint, not edge cases: each one describes something the delta cannot tell you.

  1. Snapshot granularity. The manifest is rebuilt on a schedule (default every 6 hours), so it is not real-time. POST /partner/lowest/bulk and GET /partner/lowest/{sku} remain the price of record.

  2. Market state only. The hash covers listing/market state (sizes and their price buckets). A change to product metadata does NOT appear in changed. That is the whole product object (name, model, brand, gender_size, size_type, category) and also size_map.size_type, which is product metadata even though it is delivered inside size_map. This matters: if a product's size_type is corrected (e.g. US → EU), every size key in that SKU's size_map changes meaning, the hash does not move, and the SKU never appears in changed. If you cache size_map, re-pull product metadata on your own schedule; do not rely on the delta for it.

  3. The manifest is NOT the complete catalog. It lists SKUs that have a row in our market-state store. A SKU can be priceable by GET /partner/lowest/{sku} and still be absent from the manifest, because that route can resolve a price from a source this snapshot does not read. Concretely: do not treat "absent from the manifest" as "does not exist", and do not use the manifest as your only source of SKUs to price. Conversely a SKU present in the manifest can still return 400 / {"code":"0009"} from the price routes. Crawling the manifest minimises, but does not eliminate, "SKU not found" responses.

  4. Delisting. A SKU whose listings are all withdrawn normally stays in the manifest with a changed hash and an empty size_map. It appears in removed only when its market rows are deleted outright.

  5. hash: null / price_source: "live" — the delta does NOT cover this cohort. Read this before you rely on changed.

    • price_source: "snapshot" (hash is a string): the fingerprint covers this SKU's price state. If the price moves, the SKU appears in changed. The hash is computed over the underlying market rows, so it can also flip when the visible minimum did NOT move — changed may contain a few no-op SKUs. For this cohort the delta over-reports and does not miss a price change.
    • price_source: "live" (hash is null): this SKU's price is served from a live source the snapshot cannot fingerprint, so we cannot tell you whether it moved. We do not guess. These SKUs are never reported in changed on the basis of a price move, and their price CAN move without any delta ever mentioning them. They are listed explicitly in the manifest, and live_priced_sku_count on this endpoint tells you how many there are, so the set is identified rather than hidden. You own the refresh cadence for them. Re-price them from POST /partner/lowest/bulk (or GET /partner/lowest/{sku}) on your own schedule — and pace it: these are exactly the SKUs we cannot answer cheaply, so a bulk request resolves only a handful of them and returns the rest in deferred. Currently a low single-digit percentage of the catalog and shrinking; it can temporarily become the entire catalog during an incident, which is visible as live_priced_sku_count == sku_count.
    • Membership is not permanent, so the labels in the copy of the manifest you keep go stale. A SKU crossing either way IS reported in changed, once — and because that is indistinguishable from an ordinary price move, the delta response also carries a now_live array naming which of the SKUs it reports are live-priced as of to_snapshot. Honour it: a SKU appearing in now_live has left the covered cohort, whatever your manifest copy says about it. From that point the delta will never again report its price moving; it will mention that SKU only if it crosses back (in changed, and absent from now_live) or is removed. Independently of that, plan to re-download the manifest periodically (weekly is enough) to re-baseline; a manifest you downloaded once is not permanently accurate.

    So, precisely: for SKUs in the manifest with price_source: "snapshot", the manifest → delta → bulk loop will not leave you holding a stale price, provided you also honour now_live and move the SKUs it names into your own refresh schedule. For price_source: "live" SKUs the delta is silent by design; for SKUs absent from the manifest (caveat 3) it says nothing at all. In both of those cases the price routes remain authoritative and are the only thing that will tell you the current price.

  6. Staleness. The manifest is only as fresh as the last successful build. If the builder stops, this endpoint returns 503 / code 0014 rather than serving a frozen snapshot as though it were current. Also check generated_at yourself — treat anything older than your polling interval by a wide margin as "fall back to the price routes".

Responses​

Current manifest snapshot