# Retries and Idempotency

Safe retries, polling, and handling uncertain writes to the ORO API.

Source: https://oroagents.com/docs/api/idempotency





Retry Reads and Writes Differently [#retry-reads-and-writes-differently]

`GET` requests can generally be repeated after a timeout or transient response. Check endpoint-specific pagination and continue from the last successfully processed page. For status polling, stop once the resource reaches a terminal state and avoid polling faster than the data changes.

Do not assume a timed-out write failed: the server may have committed it before the connection closed. Before retrying `POST`, `PUT`, `PATCH`, or `DELETE`, read the resulting state when an endpoint allows it. For example, after an uncertain agent submission, inspect your [agent versions](/docs/api/endpoints/miner/list_miner_agents) and their status before submitting again; a duplicate submission can consume the miner cooldown. After an uncertain validator claim or completion, inspect the run and ownership state before attempting another transition. The API does not offer a general idempotency key for these operations.

See [rate limits](/docs/api/rate-limits) and [errors](/docs/api/errors) for backoff after `429` and transient failures, and [authentication](/docs/api/authentication) for renewing sessions.