When you create, update, delete, or refund an event through the API, the response returns immediately and the heavy lifting (recurrence fan-out, ticket structure setup, Shopify product mirroring) runs asynchronously. Until now you polled that work through the sync jobs endpoint, which reported a single status and a coarse progress counter. That endpoint has grown up: it is now the operations resource, and it shows you what is actually happening inside.
What’s new
An operation now exposes a phases tree: the individual units of work it planned, each with its own status, progress, and error. For a Shopify-connected event that means you can watch tickets, catalog, inventory, metafields, delivery, and publish move independently instead of staring at one opaque counter.
That unlocks two things integrations have asked for:
- Partial readiness. The
ticketsphase completing means the ticket structure and products exist and are editable, even while Shopify-side finishing work is still running. If that is all your script needs, you can proceed without waiting for the whole operation. - Root-cause failures. When an operation fails, its
errornow names the originating phase and carries a specific, machine-readable code (for exampleINVENTORY_RECONCILE_RAISED), instead of a generic failure.
Operations also report a running status while work is in flight, so pending now means exactly what it says: planned but not started.
Renamed path and header
| Before | Now |
|---|---|
GET /events/{id}/sync_jobs/{id} |
GET /events/{id}/operations/{id} |
X-Event-Sync-Job-ID header |
X-Event-Operation-ID header |
The old path and header continue to work as deprecated aliases so nothing breaks today. They will be removed on September 4, 2026 (90 days from this announcement). Migrate to the new names before then; it is a find-and-replace.
Breaking changes if you poll this endpoint
The richer resource reshapes a few fields. If you have an integration polling sync jobs today, review these:
operationis nowaction. The field that reportssave/delete/refundwas renamed. Code readingoperationfrom the response body needs updating.runningis a new status. If your polling loop treats anything other thanpendingas done, it now stops too early, while work is still in flight. Treat onlycompletedandfailedas terminal.progresscan benull. It was previously always an object with zeroed counts; it is nownulluntil there is something meaningful to report. Guard before readingprogress.percent.sub_jobsis nowphases. If you picked up the briefly exposed (and never documented)sub_jobsarray, it is nowphases, with slimmer per-phase nodes.
Where to read more
The full contract, including every phase name, status, error code, and polling guidance, is in the Operations documentation. The bulk event import guide has been updated to use the new names throughout.
