B2B Leads API Retry Design: Recovery and Duplicate Prevention

A retry policy should repeat only the stage that failed, under a clear limit. In a lead-data workflow, retrying a destination write and repeating a paid source retrieval have different consequences.

Begin with the actual endpoint contract and record whether a usable response was already stored. The public-search error reference describes Dievio's current status and message shape; this guide focuses on the recovery decision.

A status alone may not explain the cause. For example, Dievio public search can return 500 for configuration or balance-read failures as well as unexpected errors. Repeating a configuration failure indefinitely is not a recovery strategy.

Define request timeouts, maximum attempts, maximum elapsed recovery time and the condition that pauses the whole job. These values depend on the workflow deadline, response behavior and acceptable cost; there is no universal five-retry rule for every lead API.

Store the retry state outside worker memory. Include the attempt count, earliest next attempt, failure category and recovery owner. A worker restart should not reset the attempt counter and create an endless loop.

• Use an increasing delay for recoverable repeated failures.
• Add jitter where needed to avoid synchronized workers.
• Cap the delay and the total recovery period.
• Route exhausted or unexplained failures to a review state.

If a provider supplies a documented retry delay, interpret it correctly. An HTTP Retry-After value can be a delay in seconds or an HTTP date. Do not parse every value as a decimal number.

That general HTTP behavior does not establish that Dievio always supplies a retry header or rate-limit counters. Use a bounded client policy when the response offers no documented guidance. The request-controls guide separates traffic pacing from credit limits.

Before calling Public Search, store a unique Idempotency-Key for each logical page along with its parameters. If the connection drops, resend the same key and parameters within one hour of completion. A successful replay includes Idempotency-Replayed: true and uses no additional credits.

Do not claim a provider request-status endpoint, deduplication header or billing lookup exists unless it is documented. If no definitive result can be recovered, the operator needs an explicit decision about a bounded repeat request.

For numeric pagination, preserve the job's filters and page size. Save the response and its effective pagination state before marking the page complete. Do not advance the page number after a timeout merely to keep the worker moving.

A subsequent CRM failure should leave the source checkpoint intact. Resume transformation or delivery from the saved response. The pagination workflow explains page-boundary and changing-result limitations.

Use the destination's documented idempotency contract where available. Otherwise, combine conservative matching, a stable logical delivery reference and reconciliation appropriate to the destination.

An acknowledgement can mean that a receiver accepted the job rather than completed the CRM write. Track both states. The application-owned relay guide explains why transport acceptance and final business completion must remain separate.

1. Return a temporary error and verify the delayed, bounded next attempt.
2. Restart the worker and confirm its retry history survives.
3. Simulate a dropped response and confirm the worker retries the same page with its saved key before advancing.
4. Fail the destination after source storage and confirm no extra search starts.
5. Exhaust the recovery budget and require a review decision.

Use fixtures for failure cases and a small live request to validate the real response contract. Keep recovered jobs, unresolved jobs and paid repeat retrievals visible in the final operating report.