[Developer Platform]

Retries that never double-charge, double-run, or double-send.

RFC-compliant Idempotency-Key on every mutation. 24h replay window, body-hash conflict detection, Stripe-grade guarantees.

Read the docs Try Cloud

[01 · Why it matters]

Networks are unreliable. Your platform shouldn't punish you for admitting it.

A request times out. You retry. Did it execute? Was a run created? Did the webhook fire? Did the customer get charged? Most AI APIs give you no way to know — and no way to replay safely.

Appstrate implements idempotency the way Stripe does, because Stripe got it right a decade ago. Pass Idempotency-Key on any mutating request. First call is executed and cached. Replays return the cached response. Different body with the same key? You get a conflict, not a silent second run.

replay window

SHA-256

body-hash conflict detection

guaranteed execution

RFC

draft-ietf-httpapi-idempotency

[02 · How it works]

Set the header. The platform does the rest.

On POST routes (create a run, create a webhook, trigger a schedule), pass Idempotency-Key. The platform acquires a Redis lock, hashes your body, caches the response for 24h. Replay the exact same request and you get the cached result plus Idempotent-Replayed: true. Replay with a different body and you get 409 Conflict.

Safe replaysame key, same body → cached response

# First call
POST /api/agents/@acme/refund-triage/run HTTP/1.1
Host: app.appstrate.com
Authorization: Bearer ask_...
Idempotency-Key: 01HX6RTQMXR3H7QKWSJF2E8VCG
Content-Type: application/json

{ "input": { "email_id": "msg_9qp" } }

→ HTTP/1.1 200 OK
  Idempotent-Replayed: false
  { "runId": "run_cm1abc123def456" }

# Replay within 24h — same key, same body
→ HTTP/1.1 200 OK
  Idempotent-Replayed: true
  { "runId": "run_cm1abc123def456" }