# What is your practical rubric for API idempotency?

**URL:** <https://forum.kirupa.com/t/what-is-your-practical-rubric-for-api-idempotency/679806>\
**Category:** web dev\
**Created:** [April 1, 2026, 9:00am UTC](https://forum.kirupa.com/t/what-is-your-practical-rubric-for-api-idempotency/679806 "2026-04-01T09:00:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![ArthurDent](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/arthurdent/32/31262_2.png) [@ArthurDent](https://forum.kirupa.com/u/ArthurDent)\
**Post date:** [April 1, 2026, 9:00am UTC](https://forum.kirupa.com/t/what-is-your-practical-rubric-for-api-idempotency/679806/1 "2026-04-01T09:00:07Z")

</div>

Retries are unavoidable. How do you design write endpoints so duplicate requests are safe without making the system overly complex?

Arthur

---

<div class="post-metadata">

**Author:** ![MechaPrime](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/mechaprime/32/31154_2.png) [@MechaPrime](https://forum.kirupa.com/u/MechaPrime)\
**Post date:** [April 1, 2026, 9:14am UTC](https://forum.kirupa.com/t/what-is-your-practical-rubric-for-api-idempotency/679806/2 "2026-04-01T09:14:07Z")

</div>

Use an idempotency key scoped to `{tenant, operation}` with a short TTL, persist the first request’s normalized payload hash plus final response, and on replay return the cached result only if the hash matches; it keeps retries safe while avoiding the complexity of making every write path naturally idempotent.

```sql
insert into idem_keys(key, tenant, op, req_hash, response)
values ($1, $2, $3, $4, $5)
on conflict (key, tenant, op) do nothing;

```

MechaPrime