Catalog API Documentation

Browse endpoints, parameters, and live request examples.

Fulfillment Only Integration

This page is for teams that already run a storefront and are not going to replace it. If that is not you, use the full API instead. The catalog, search, and cart endpoints power the shopping experience for you, the catalog stays live without you scheduling a refresh, and it is the shorter route to something working.

If you do have a storefront, you can load the catalog into your own system and use CatalogAPI only to place orders and track fulfillment. Your search, merchandising, and checkout stay yours. It is a different path rather than a lighter one: it trades a live catalog for keeping the shopping experience you already built.

How it works

  1. Download the catalog. Every catalog socket comes with a SQLite file of its catalog.
  2. Ingest it. Drop the file into your application and query it the way you query anything else you own, or load it into your existing product tables. Your search, merchandising, and checkout stay yours.
  3. Place and track. Call the order endpoint directly when a user checks out, then follow fulfillment by polling order tracking or receiving webhooks. No browse calls, no cart calls.

The catalog file

The file is regenerated several times a day. Refreshing daily is a sensible default.

It arrives as a complete file rather than a delta feed, on purpose. You swap the database out rather than reconciling changes into it, which keeps ingestion simple and removes a class of drift bugs.

Items from your own products appear in this file too, so being set up as a supplier does not require a second integration path.

Placing an order against a snapshot

Placing an order this way runs the same validations the cart flow would, including price validation and whether the item requires a shipping address.

That means a snapshot which has drifted since you ingested it fails at order time rather than quietly placing a wrong order. It is a distinct path that bypasses the cart, not a thinner one.

Check you want this path

Use the catalog, search, and cart endpoints instead when you want CatalogAPI to power the shopping experience itself, when you want catalog changes to appear the moment they happen rather than at your next refresh, or when you are starting without a storefront and would otherwise be building search and merchandising yourself. That is the default integration, and this one exists for the case where replacing your storefront is not on the table.