Bale API¶
The Bale adapter provides the typed asynchronous client and Bale-specific
request/response models. The generated reference below recursively discovers
the restructured types and methods packages.
Client¶
Bale platform public API.
Types and methods¶
Bale API types, one file per type. |
|
Bale client methods, one module per method. |
Supporting modules¶
Bale application-level API errors.
Every Bale response is a JSON envelope with an ok flag. On ok: false, Bale still returns a plain HTTP 200 – the failure is encoded in the JSON body (description + error_code + optional parameters), not in the HTTP status line. That makes it an application-level failure, distinct from peyk.transport’s transport-level errors (HTTPStatusError, NetworkError, TimeoutError_, RateLimitedError), which are raised from transport-level facts only (connection failures, timeouts, non-2xx status codes).
BaleAPIError subclasses peyk.transport.errors.TransportError so it can still be caught alongside transport errors by callers that want a single “something about this Bale call failed” catch-all – but it is deliberately not included in peyk.transport.retry.DEFAULT_RETRYABLE, and BaleClient never passes it through run_with_retry in the first place (see client.py): a run_with_retry-wrapped call to Session.request() already returns successfully (HTTP 200, valid JSON) before BaleClient ever looks at the ok flag, so the retry layer never even sees a BaleAPIError to (correctly) decline to retry.
- exception peyk.platforms.bale.errors.BaleAPIError(message: str, *, error_code: int, description: str, parameters: object | None = None)[source]¶
Bases:
TransportErrorRaised when a Bale API response has ok: false.
- Variables:
error_code – Bale’s error_code integer from the response body.
description – Bale’s human-readable description string.
parameters – The optional parameters object Bale sometimes includes alongside an error (e.g. retry hints for specific error codes). None when absent.