Delivery

Transient vendor rate limits (429) and 503 are retried with backoff on the Bitlync side of the write.

Mechanism

The caller sends one write. Bitlync retries the vendor when the failure is transient. The caller is not asked to implement vendor backoff for those hops.

What the caller sees

The caller sees one result. If the write still cannot land, the final rate-limit response (429) still carries the vendor Retry-After.

HTTP 429
Retry-After: 30

{
  "status": 429
}

No hidden swallow of a vendor rate limit (429). No rewrite of a final rate limit into a 200.

Delivery status is visible. Nothing is dropped silently.

Mechanism

A write that was acknowledged cannot double-write. A write that was throttled is a real rate-limit response (429), not a delayed success. Dedup and retries sit on this same rule.

What the caller sees

Success means the write landed or was an idempotent replay. Throttle means a rate-limit response (429) plus Retry-After.

{
  "idempotent_replay": false
}

No silent drop. No “accepted” that later vanishes.

Writes that support it take idempotency_key. The same key does not open a second ticket.

Mechanism

Send the key on the write. A retry with that key is a replay, not a new vendor create.

What the caller sees

The replay is marked idempotent_replay.

{
  "summary": "Printer offline",
  "dry_run": false,
  "idempotency_key": "ticket-1"
}

{
  "status": "ok",
  "idempotent_replay": true
}

Keys are not implied on every future write. Only writes that already support idempotency_key.

Webhooks

Outbound signed events (ticket / device / company) moved to Webhooks. Register, Bitlync-Signature, retry / 410 / grant_missing live there. Poll remains GET /tenants/{id}/connections/events?kind=….