Idempotency

An operation is idempotent when repeating it leaves the system in the same state as doing it once. On this API the picture is short: almost everything you'll call is a read, and the few writes sort cleanly.

Reads: repeat freely#

The observe side of the surface — program runs, programs, quality reports, capture files — is all GET. Retry on any failure without ceremony; nothing changes server-side. (Errors and retries covers which failures are worth retrying.)

There is no idempotency-key mechanism — no Idempotency-Key header to send. The write surface is small enough that the semantics below cover it.

Writes: webhook management#

• PATCH /webhooks/{webhook_id} and DELETE /webhooks/{webhook_id} are idempotent in effect — repeating a patch reasserts the same fields; a second delete finds nothing to delete.
• POST /webhooks is not idempotent: retrying a create that actually succeeded registers a second, identical webhook — and your endpoint then receives every event twice. If a create times out, list /webhooks and check before retrying.
• POST /webhooks/{webhook_id}/test and POST /webhook-deliveries/{delivery_id}/retry are safe to repeat: a test sends another disposable event, and a retry re-arms the same delivery with the same event_id.

The idempotency that matters is yours#

Cheetah delivers events at least once, so the load-bearing deduplication lives in your receiver and your store: dedupe deliveries on event_id, upsert records keyed on run_id. That design — and why it also makes manual replays safe — is covered in Webhooks. Built that way, the same key handles API-side re-reads too: a sync loop that sees a program run twice writes one row.