Idempotency and retries - DataVibe Documentation

Set a stable idempotency_key for every logical send. Reusing it for a retry returns the original action instead of creating a second billable submission.

{
  "recipient": "prospect@example.com",
  "subject": "Following up",
  "body_text": "Hi Jordan — checking in.",
  "body_html": "<p>Hi Jordan — checking in.</p>",
  "idempotency_key": "campaign-42-send-1001"
}

Retry rules

Retry transient 429 and 503 responses only after the indicated delay.
Preserve the same idempotency key and payload.
Do not retry authentication or validation failures unchanged.
Do not create a new key to bypass a pending QUEUED action.
Treat a conflicting payload for an existing key as an integration error.

Use exponential backoff with jitter and honor Retry-After, reset_at, and next_step fields when returned.

Never dispatch a second copy because a status poll timed out. Poll the existing action_id before deciding whether any retry is safe.

Last modified on July 23, 2026

⌘I

​Retry rules

Retry rules