Skip to content
DEV preview — API version 1.0.0 — not the public production site — Development API: dev-api.theprioryshop.co.uk
EPOS Developer API

Catalog Sync

There are no webhooks yet (see Events & Webhooks), so keeping your own copy of the catalog current means polling on a schedule with updatedSince, not re-fetching everything every time.

Pattern

Section titled “Pattern”
  1. First run: fetch everything, paginating through GET /v1/catalog/products (and GET /v1/catalog/categories, which isn’t paginated) with no updatedSince. Store updatedAt for every record you save, and record the time your sync run started.
  2. Every subsequent run: fetch only updatedSince=<the start time of your last successful run>, still paginating. Upsert what comes back into your own store, keyed by id.
  3. Record the new “last successful run” timestamp only after the run completes successfully. If a run fails partway through, retry with the same updatedSince you started with, not a fresh one - so you don’t silently skip records that changed during the failed run.
Terminal window
# First run - everything
curl "https://dev-api.theprioryshop.co.uk/v1/catalog/products?pageSize=100&page=1" \
  -H "Authorization: Bearer epos_dev_sk_example_not_real"


# Later runs - only what changed since 2026-08-20T00:00:00.000Z
curl "https://dev-api.theprioryshop.co.uk/v1/catalog/products?pageSize=100&page=1&updatedSince=2026-08-20T00%3A00%3A00.000Z" \
  -H "Authorization: Bearer epos_dev_sk_example_not_real"

Categories change less often than products

Section titled “Categories change less often than products”

Categories aren’t paginated and there are typically far fewer of them per store than products - a simple “fetch the whole list every run” is usually fine and simpler than tracking updatedSince/pagination state for a small dataset, but updatedSince works there too if you prefer consistency with your product sync.

Promotions

Section titled “Promotions”

Promotions have no updatedSince filter - they’re typically few per store and change less predictably (a promotion can start/stop based on startsAt/endsAt without any record being “updated”). If your integration needs to reflect currently-live promotions, poll GET /v1/catalog/promotions (default activeOnly=true) on a schedule that matches how often you need that to be fresh, rather than trying to sync it incrementally.

Don’t poll faster than the data changes

Section titled “Don’t poll faster than the data changes”

See Rate Limits for the general guidance - pick an interval that matches your actual freshness needs, not “as often as possible.”