What happens to one write
Every step is a record you can read back.
Integrations fail in the gap between “we sent it” and “it worked”. This is
what the runtime does with that gap.
-
Signed, then read
Your backend signs the request. The runtime checks the timestamp window, looks up your key, decrypts it, and compares the signature in constant time — and only then writes the replay nonce. An unverified request writes to no database and alters no customer data — it is still counted against the abuse limits that run ahead of authentication, which is the point of putting them there.
-
Admitted, one connection at a time
Each connection has its own coordinator holding the serialization slot, the rate budget and the circuit state. Two writes on the same connection never race, and that connection's share of the provider rate limit is spent deliberately rather than discovered by getting throttled.
-
Reserved before the call
A reservation row is written before the provider is contacted, and stamped again the moment the call starts. If the runtime dies mid-flight, the next attempt can tell the difference between “never sent” and “sent, outcome unknown”.
-
Called with a stable key
The create carries an idempotency key derived from yours. A retry replays the original response rather than creating a second invoice. Duplicate safety is the provider's guarantee, not a search-and-hope afterwards.
-
Linked
On success the reservation flips to linked with the provider's identifier and sync token. That mapping is what stops the same object being created twice, on any later attempt, from any replay path.
-
Reported back
When the job reaches a terminal state, a signed webhook carries the outcome to whatever endpoints you have configured for that event. Delivery is best-effort by design and never blocks the job, so the record itself is the source of truth: the whole attempt, including every failure, stays queryable at GET /v1/sync-jobs.