Skip to main content

The recurring CRM sync — the switch, and what it last did

GET 
/api/integrations/:provider/sync

Keeping the two systems current on a timer, in the DIRECTION the ownership setting already names: a class owned by us is pulled (new records arrive; nothing here is ever overwritten), a class owned by the CRM is pushed (nothing is imported — it never was), and a class set to both moves in both directions for as long as that declared migration lasts. A class nobody has decided does nothing at all and gets no row: direction is then null.

There is no second switch saying which way a class moves. Two settings that can disagree about the same fact is how a workspace ends up pulling into a class it declared its own.

This half of the endpoint is the point. The takeover shipped without visibility and cost two hours in front of a screen reporting zero of everything. A job that runs every hour is worse placed to survive that, because it fails by quietly not running — no error, nothing in a log. So the response carries when a pass last ran, how far its window reached, what it brought, why it stopped, and stalled: a pass marked running whose heartbeat has stopped is a worker that is gone, and the server says so rather than leaving two timestamps for a panel to compare.

recurring_domains names the classes a pass can serve at all. Quotes, sales and balances are absent because they are read PER CUSTOMER on this port, so a recurring pull of them would cost one call per linked person per pass — a clinic with three thousand linked patients would spend a third of its daily allowance on one sweep. Bringing those across is what a takeover is for: deliberate, and once.

The catalogue is served, and its direction does NOT come from the ownership rule the record classes use. A catalogue is a list one system OWNS rather than a thing that happens in either, so "it lives in their system" means PULL — mirror theirs — where for an appointment the same answer means push. There is no catalogue push at all: this port can write catalogue items and cannot read their prices back, so a push would be a one-way write into somebody's menu with no way to check what it did.

This is POLLING. The Stella settings screen deliberately does not subscribe to the clinic's webhook, because subscribing would displace whoever receives it today — so the honest bound on freshness is interval_minutes plus one scheduler tick.

Request​

Responses​

The switch, the rhythm, and every class this can serve.