Skip to main content
Network calls fail and get retried — that’s a fact of distributed systems. Without a way to deduplicate retries, a transient timeout can cause the same operation to run twice, costing credits twice and potentially returning duplicate results. fetchbean solves this with the Idempotency-Key header, which makes any call exactly-once safe regardless of how many times you send it.

​
Sending an idempotency key

Add the Idempotency-Key header to any request. Use a unique value per logical operation — a UUID is the best choice:
Generate a fresh UUID for each distinct operation. Reuse the same UUID only when retrying the same logical request — for example, after a network timeout on the original attempt.

​
Retry behaviour

The outcome when you resend a request with the same key depends on the state of the original call:

Original succeeded

fetchbean returns the original result immediately. You are not charged again — no second reserve, no second settle.

Original in flight

fetchbean returns a request_in_progress response instead of dispatching a second call. Wait and retry.

Original failed

The key is spent. Use a new key for your next attempt — the failed call is not replayed.

No key sent

fetchbean generates a unique key for you automatically. Every call without a key is treated as a distinct operation.

​
Billing protection

Idempotency and billing are tightly coupled in fetchbean. A call that reserves credits upfront only ever settles once — a same-key retry never triggers a second reservation or a second charge. This means you can safely retry on timeouts, connection drops, or any network error without worrying about being billed multiple times for a single logical operation.
If you omit the Idempotency-Key header entirely, fetchbean assigns a generated key automatically. This means every headerless call is treated as a unique request — no deduplication occurs.