Errors

Every API method resolves to Result<T, ApiError>. Match ApiError rather than parsing error strings, and keep request identifiers in your own logs when handling failures.

match client.retrieve_a_record("rec_123", None).await {
    Ok(response) => println!("{}", response.data.name),
    Err(ApiError::NotFoundError { message, .. }) => {
        eprintln!("Record does not exist: {message}");
    }
    Err(ApiError::UnauthorizedError { message, .. }) => {
        eprintln!("Check the bearer token: {message}");
    }
    Err(ApiError::Network(error)) => {
        eprintln!("Transport failed: {error}");
    }
    Err(error) => return Err(error),
}

HTTP and client errors

The generated client maps status codes 400, 401, 403, 404, 409, and 500 to BadRequestError, UnauthorizedError, ForbiddenError, NotFoundError, ConflictError, and InternalServerError. Each has a server message and optional structured error. Other statuses become ApiError::Http { status, message }.

Network(reqwest::Error) indicates a transport-level failure. Serialization(serde_json::Error) means the request could not be encoded or a response could not be decoded. Configuration, InvalidHeader, and RequestClone are client-side setup/retry failures. The enum also contains streaming-related cases, but these documented operations are ordinary request/response calls.

Retry discipline

The client defaults to three retries; adjust it with Configuration. Do not blindly retry a state-changing call after a timeout or network error, because the server may have applied it even though the response was lost. For ingestion or appeal submission, make the workflow idempotent using stable external IDs where possible and reconcile with retrieval/listing.

Option<T> fields in response models represent values the API may omit or return as null. A successful HTTP call can therefore have None for fields such as an asynchronous moderation ID or an appeal URL. Handle that separately from Err(ApiError).