Client Configuration
flywheel.Client is the entry point for all SDK operations. When you initialize it, you control how the client connects, authenticates, and behaves at runtime.
See Getting Started for installation and basic authentication patterns.
Constructor Parameters
| Parameter | Type | Default | Description |
|---|---|---|---|
api_key | str | None | API key. When omitted, the client reads credentials from ~/.config/flywheel/user.json (set by the Flywheel CLI). |
disable_auth_check | bool | False | Skip the authentication check on initialization. Required when using drone or device keys. |
request_timeout | int | 60 | Read timeout in seconds. |
connect_timeout | int | 10 | Connection timeout in seconds. |
exhaustive | bool | False | Return complete lists regardless of group/project permissions (Site Admin only). |
import flywheel
fw = flywheel.Client(
api_key="your-api-key",
request_timeout=120,
connect_timeout=30,
exhaustive=True,
)
Timeouts
The client applies two independent timeouts to every HTTP request:
- Connect timeout (
connect_timeout): How long to wait when opening a TCP connection. Default is10seconds. - Request timeout (
request_timeout): How long to wait for the server to send a complete response after connecting. Default is60seconds.
Both can also be set with environment variables — useful in environments where you cannot pass arguments directly to the constructor, such as inside a Flywheel gear.
export FLYWHEEL_SDK_CONNECT_TIMEOUT=30
export FLYWHEEL_SDK_REQUEST_TIMEOUT=120
Constructor arguments take precedence over environment variables. When neither is set, the defaults (10 and 60) apply.
Per-request timeout override
You can override the timeout for a single call by passing _request_timeout as a (connect_timeout, request_timeout) tuple in seconds:
Retries
The SDK automatically retries requests that fail due to transient errors. By default, up to 7 retries are attempted with exponential backoff.
Retried status codes
| Status | Meaning |
|---|---|
429 | Too Many Requests |
502 | Bad Gateway |
503 | Service Unavailable |
504 | Gateway Timeout |
Retries apply to idempotent HTTP methods: GET, HEAD, PUT, DELETE, OPTIONS, TRACE, and PATCH. POST requests are not retried automatically.
Default retry schedule
The first retry is immediate. Each subsequent retry waits progressively longer before the next attempt:
| Attempt | Wait before attempt |
|---|---|
| 1st retry | 0 s |
| 2nd retry | ~1.9 s |
| 3rd retry | ~3.75 s |
| 4th retry | ~7.5 s |
| 5th retry | 15 s |
| 6th retry | 30 s |
| 7th retry | 60 s |
Adjusting retry behavior
Retry behavior is controlled by environment variables. Set them before your process starts or before importing the SDK.
| Variable | Default | Description |
|---|---|---|
FLYWHEEL_SDK_TOTAL_RETRIES | 7 | Maximum number of retry attempts. |
FLYWHEEL_SDK_BACKOFF_FACTOR | 1.875 | Controls the delay between retries. Higher values produce longer waits. The effective wait grows as backoff * 2^(N-1) seconds for retry N. |
Note
There is no constructor parameter for retries. The only way to configure retry behavior is through these environment variables.
Exhaustive Mode (Site Admin only)
By default, listing endpoints return only the containers the authenticated user has permission to see. With exhaustive=True, the server returns all matching containers across the instance, regardless of per-user permissions.
fw = flywheel.Client(api_key="your-api-key", exhaustive=True)
# Returns all projects site-wide,
# regardless of group/project permissions for the API key user
all_projects = fw.projects.find()
This mode is intended for site administrators building scripts that must operate across the full instance — for example, audit scripts, bulk migrations, or reporting tools.
Warning
exhaustive=True requires site administrator access. Non-admin users who enable this flag will not receive expanded results, but some endpoints may behave unexpectedly.
Debug Mode
Debug mode logs the full HTTP wire traffic — request headers, request body, and response — using Python's standard logging infrastructure at DEBUG level. It also activates low-level logging via http.client.
Enabling debug mode
Call fw.enable_debug() on an initialized client:
import logging
logging.basicConfig(level=logging.DEBUG)
fw = flywheel.Client(api_key="your-api-key")
fw.enable_debug()
# Subsequent requests log full HTTP traffic
fw.get_current_user()
Configure logging.basicConfig (or your own log handler) before making requests, otherwise the DEBUG-level output will not appear.
Truncating large messages
Upload bodies and bulk list responses can produce very large log entries. Pass message_cutoff to limit how many characters appear in each log message:
When a message exceeds message_cutoff, the log shows the first and last cutoff // 2 characters separated by a ...[N bytes total]... summary.
Disabling debug mode
Releasing Resources
The client maintains a connection pool and a thread pool internally. Both are released automatically when the Client object is garbage-collected. To release them explicitly — for example, at the end of a long-running script — call: