Skip to main content
The Sync Server keeps a tenant’s commerce systems agreeing with each other: Shopify with NetSuite, a 3PL with the order book, inventory with every channel that sells it. This API is how a tenant drives it — trigger and inspect syncs, read and write orders, receive and replay webhooks, and watch the jobs that do the work.
Every endpoint here is tenant-scoped: the tenant id is in the path, and the key must belong to it. The server also carries a 38-operation admin surface under /v1/admin behind an admin key — platform diagnostics, tenant policy, audit — which is operated by StateSet and not listed.
Every success body is wrapped: { "meta": { "requestId": "…" }, "data": … }. The response fields on each page describe data; the wrapper is the same everywhere and is not repeated. Errors use the same meta with an error object instead of data.

​
Where to start

Trigger a sync

Orders, inventory, products — per integration, with the job id you then watch.

Watch the jobs

Queued, running, succeeded, retrying, failed, dead-lettered — and why.

Receive webhooks

Register endpoints, read the events the platform recorded, replay one that failed.

Read and write orders

The order book as the sync sees it, with idempotent writes.
Every write takes an Idempotency-Key. Reusing a key with a different body returns idempotency_conflict rather than a second order — so after a timeout, retry with the same key and check the job rather than retrying blind.