Response times

Ampere is a request/response REST API. Latency depends on the endpoint class, the size of the requested window, and how much data must be resolved for the caller’s scope.

We do not publish a single fixed SLA number in this documentation set. Treat contractual SLAs, if any, as the authoritative commercial commitment; the guidance below is the operational model partners should design against.

What partners should expect by endpoint class

Class	Examples	Typical behaviour
Auth and identity	login, refresh, `/auth/me`	Fast, lightweight
Metadata / inventory	list groups, list devices at an address	Usually quick; grows with portfolio size
Point-in-time state	latest meter reading, latest production state	Usually quick
Time-series / aggregates	meter intervals, P4 energy, production history, flex aggregation	Slower as date ranges grow
Forecast / compute	battery forecast, delivery/return forecast, production forecast	Often the slowest class; may depend on freshness of upstream state

Design implications

Interactive UIs should use short timeouts and narrow windows.
Background sync jobs should use longer timeouts and incremental ranges.
Prefer “latest” endpoints when you only need the current snapshot.
Prefer pagination and bounded limit/offset where available instead of unbounded full dumps.
Retry only transient failures (429, some 5xx) with exponential backoff; do not blindly retry every timeout.

Practical client defaults

These are starting points, not guarantees:

Workload	Suggested client timeout
Auth and inventory	5–10 seconds
Single-resource state	10–15 seconds
Time-series over a day or less	15–30 seconds
Broad historical or forecast compute	30–60 seconds

If a call regularly approaches your timeout, reduce the date range or split the job rather than raising retries alone.