Retries and Timeouts

max_network_retries defaults to 3 retries after the first attempt; 0 disables SDK retries. Reads and retryable transfer requests can retry temporary failures. Requests that change data are treated more cautiously, as below.

open_timeout defaults to 30 seconds for connecting to each resolved address; read_timeout defaults to 80 seconds for each response read. These limit stalls, not total operation duration. Use request_timeout or deadline for an overall limit; see Cancellation and Deadlines.

Choosing Retry and Timeout Settings

import files_sdk

try:
  with files_sdk.Client(api_key="YOUR_API_KEY", read_timeout=300, max_network_retries=5) as client:
    client.group.create({"name": "Auditors"}, {"max_network_retries": 0})
except files_sdk.error.NotAuthenticatedError as err:
  print(f"Authentication Error Occurred ({type(err).__name__}):", err)
except files_sdk.error.Error as err:
  print(f"Unknown Error Occurred ({type(err).__name__}):", err)

Sending a Request Again

Request	Retry behavior
Connection failure before sending	Can retry within the budget.
Read, such as `GET`	Also retries timeouts, lost answers, HTTP 429 and 5xx other than 501.
Request that may change data	Not replayed once it may have reached Files.com, including after an error response.
Upload part or part-URL request	Repeatable requests retry within the transfer rules; accepted parts are not replayed.
Download	Bound ranges retry individually; a whole response restarts only while the destination can restart. Already-written stream bytes are never replayed.

Retries send the same body, including attachments. A mutating request can take effect before an error, even HTTP 429 or 503. remote_outcome_unknown = True on APIConnectionError or the API error means check the outcome before repeating the change. A site-disabled response (HTTP 422, service-unavailable/site-disabled) is the specific exception: it precedes the change and has a false flag. Do not treat other error statuses or bodies as proof that nothing happened.

Regional Relocation consumes one retry. TLS certificate failures, unsupported URLs, excessive redirects, caller-code exceptions and cancellation are not retried. A custom http_session adapter performing retries can still replay requests outside the SDK's policy; see Clients.

Destination	Wait before retry
Files.com API	0.1, 0.2, 0.4 seconds by default, doubling from `initial_network_retry_delay` to `max_network_retry_delay` (2 seconds).
File transfer after HTTP 429 or 503	The `Retry-After` delay, up to 60 seconds at a time, or no wait without it.
Other retryable transfer failure	0.1 seconds.

Retries are logged at INFO with the reason and wait. Uploads and Downloads describe completion ambiguity and transfer-specific recovery.

Redirects, Credentials and Proxies

max_redirects defaults to 30 per request. API credentials, Workspace and extra headers stay with the configured API origin. After a redirect changes scheme, host or port, only generic headers remain, even if it later returns. Signed transfer requests carry none of those API credentials; version-bound downloads have stricter redirect rules.

The SDK never uses .netrc credentials. It honors HTTP_PROXY, HTTPS_PROXY, NO_PROXY, REQUESTS_CA_BUNDLE and CURL_CA_BUNDLE unless trust_env=False. proxies, verify and cert behave as in requests.Session. Certificates are verified unless you disable verification.