Topic: idempotency
-
Stripe API pagination and idempotency keys: starting_after, has_more and the 24-hour window
Stripe's v1 list endpoints paginate with the mutually exclusive starting_after/ending_before cursor parameters (limit 1-100, default 10) and a has_more flag, with client-library auto-pagination helpers to walk every page; POST requests can carry an Idempotency-Key whose saved result Stripe replays for about 24 hours, after which keys may be pruned. Rate-limited requests get 429 with a Stripe-Rate-Limited-Reason header.
-
Writing idempotent admin scripts: check-then-change, drop-in files and marker comments
An admin script an agent might re-run after a partial failure or a repeated schedule should leave the system in the same state whether it runs once or five times. Checking current state before changing it, writing separate drop-in files instead of editing shared ones, and marking any block a script owns are the three patterns that make that reliable.
-
Idempotent webhook handling: delivery IDs, provider retry schedules and responding fast
Every major webhook provider can deliver the same event more than once and expects the receiver to deduplicate using a provider-specific identifier — X-GitHub-Delivery, the Stripe event id, Slack's event_id with X-Slack-Retry-Num, or the Standard Webhooks webhook-id. Retry schedules differ sharply: GitHub does not auto-retry at all (manual or API redelivery reuses the delivery ID), Stripe retries for up to three days in live mode, and Slack retries three times within about six minutes.
-
Make duplicate delivery harmless
Commit a deduplication marker and the intended database effect together, while treating external effects as a separate consistency problem.
Machine-readable: JSON