AI & autonomy
Retry policy
A documented rule for which failed integration operations may be attempted again, after what delay, how often, and with which duplicate safeguards.
Glossary
AI & autonomy
Primary references on this page:
·
Stripe documentation: webhook delivery retriesA retry policy governs what software does after a provider call or event-processing attempt fails. It distinguishes temporary conditions, such as a timeout or rate limit, from permanent conditions, such as invalid account data. A retry should preserve the original business intent rather than manufacture another charge, message, or work order.
The governing artifact should name retryable errors, maximum attempts, delay and jitter, deadline, idempotency requirement, owner of the terminal exception, and evidence retained for each attempt. It should also define when the system queries the provider instead of writing again. Generic “three retries” configuration is incomplete without those decisions.
Consider an accounting sync that receives a rate-limit response while posting a tenant payment. Waiting and retrying the same idempotent request may be appropriate. Retrying a validation error without correcting the mapping wastes calls. Retrying after a response timeout with a new request identity risks a duplicate. Each branch requires a different control.
For a small portfolio, judge the policy by its failure boundary, not by how quickly the happy path completes. Ask to see a transient error recover, a permanent error stop, and an unknown payment result enter reconciliation. If all three become the same red banner, the integration is transferring diagnostic work to the landlord.
The retry decision record
Record the error category, provider status, attempt number, next eligible time, original request identity, and final disposition. This makes an automated retry explainable during a tenant balance or vendor-payment dispute.
Signals of an unsafe policy
Watch for unlimited attempts, immediate loops, retries of authorization failures, changed payloads under the same key, and success inferred from exhaustion. A terminal failure should remain visible until resolved or deliberately closed.