Idempotency-key support in Get2Dial’s API is narrow today — one endpoint, not a general
guarantee across every POST.
How it works
POST /api/v1/campaigns/{id}/status (starting, pausing, or stopping a campaign) accepts an
Idempotency-Key header. Send the same key with the same request body and you get back the
cached result of the original request rather than a second execution. Send the same key with
a different body and the request is rejected — Get2Dial won’t guess which one you meant.
A key is only remembered for 60 seconds; after that, reusing it starts a new request.
No other endpoint currently honors Idempotency-Key. Sending it elsewhere is silently
ignored — it doesn’t error, but it also doesn’t protect you.
When to use it
Use it on campaign start/pause/stop calls specifically when your own retry logic might
resend a request — a network timeout where you don’t know if the first attempt landed, for
example.
What it affects
Nowhere else in the API. For endpoints without idempotency-key support, design your own
retry logic to check state before retrying — for example, list leads before re-importing a
file, rather than assuming a retry is safe by default.
Next steps