“Retry on error” is not a complete integration policy. A failed read, a rejected validation request and a write whose response was lost require different decisions. Define those paths before the first busy event depends on the integration.
Classify the operation
Reads can usually be retried within a bounded policy because they do not intentionally create another business action. Writes need closer review. A check-in, invitation send and waiver submission have different duplicate consequences.
Save your own logical operation identifier before a mutation. Keep the endpoint, source object and intended action together so an operator can understand an uncertain result without reconstructing a browser session.
Correct rejected requests
A 401 or 403 needs credential or permission work. A 422 needs corrected values. A 409 needs reconciliation with current state, such as an event that has closed. Repeating these requests unchanged adds noise and can hide the actionable message.
A 429 should respect retry-after. Keep the job queued and coordinate workers sharing the same key. Use rate-limit guidance rather than starting independent immediate retries.
Reconcile uncertain writes
A transport timeout may happen after the server accepted the action. For waiver submission, reuse the saved idempotency key. For other operations, inspect available resource state and your own operation history before repeating the mutation.
Do not assume every POST supports idempotency because one endpoint does. Repeated check-ins can represent real repeat arrivals, so the API cannot simply discard every similar-looking action.
Make recovery visible
Show operators a distinction between rejected, pending and uncertain. An uncertain action needs review, not a green success badge or an automatic request to make the participant sign again.
Keep request IDs in the support trail. Exclude bearer keys, signature images and full personal answers from ordinary diagnostic logs. Set a retry limit and a clear owner for jobs that remain unresolved.
Test a dropped response, expired credentials, rate limiting and a worker restart. A dependable integration should resume known work and clearly surface the work it cannot safely decide on its own.