First 200 users get the Growth plan for $19/mo.

Claim
overads
Browse the docs
Overview

Start

Idempotency

The Idempotency-Key header: replay, conflict and in-flight semantics on every write.

Every POST, PATCH and DELETE on /public/v1 accepts an Idempotency-Key header. Send one on every write so a retry after a timeout cannot create the same post twice.

Idempotency-Key: 4d2f0c8e-launch-post

The rule

  • The key is scoped to the workspace and lives 24 hours. Up to 255 characters; a UUID is a fine choice.
  • The fingerprint is the method, the path and the JSON body with keys sorted. Serialising the same body in a different key order still matches.
  • Same key, same fingerprint, finished: the stored response is replayed with its original status and a Idempotency-Replayed: true header. Nothing runs again.
  • Same key, same fingerprint, still running: 409 with code IDEMPOTENCY_IN_FLIGHT. Wait and retry.
  • Same key, different fingerprint: 422 with code IDEMPOTENCY_KEY_CONFLICT. Your retry loop reused a key for a new request.
  • A failed attempt releases the key, so a retry after a 4xx or 5xx runs for real.
  • No header: the write runs every time it is sent.

Over MCP

Write tools take an optional idempotencyKey argument backed by the same store. The fingerprint there is the tool name plus the arguments, so a key used on REST and again on MCP with different arguments is a conflict.

Failure mode

If the idempotency store is unreachable the write proceeds without deduplication and the outage is logged. The API never refuses a write to protect against a retry.