Safe retries
Recover a lost response without accidentally creating another task.
Save the task identity first
Generate a UUID v4 once for each new task. Persist it with the exact URL, format, waitFor and analysis values before sending POST /scraping/tasks.
The Idempotency-Key becomes the task ID. Do not generate a new key inside a retry loop.
Recover an uncertain response
If the connection drops or times out, GET /scraping/tasks/{original-key} first. If it exists, continue with that task. If it returns 404, you can replay the original POST with the same saved key and request.
An identical replay returns the saved task, including a failed, review or expired task. It does not restart processing. Reusing the key with different request data returns 409. Do not fix that conflict by blindly generating a new key.
Respect limits and review states
For HTTP 429, wait at least the Retry-After value, currently 60 seconds. Active-task or rolling daily limits may require a longer wait. Space polling across all your integrations because the account rate limit is shared.
For review or SUBMISSION_UNCONFIRMED, contact support and preserve the task ID. For a confirmed failure, first address the reason, then explicitly decide whether a new task is needed.