Rate limits

The server applies separate request classes for data, API tokens, authentication, recovery, sessions and expensive work. Quotas are backed by shared storage rather than a browser-local counter.

Respond to 429

1. Read Retry-After and the rate-limit headers.
2. Pause the affected request stream for the indicated interval.
3. Reduce polling or batch the work where the endpoint supports it.
4. Retry with a bounded policy and retain the original financial intent when relevant.

Do not hard-code a throughput guarantee from a single successful test. Read and import work share resources with interactive users.

Separate reads from actions

A background reader can use bounded backoff. Sign-in, recovery and money recording should follow explicit user intent. A password recovery loop can exhaust limits without improving email delivery.

For a timed-out financial write, rate-limit recovery does not replace the idempotency rule. A new command key is not a retry of the old action.

Keep diagnostics safe

Record status, retry interval and request identifier, not credentials or complete response bodies. A limiter storage outage is a service availability issue; it is not permission to bypass quota enforcement.

Use client integration for transport patterns and errors for distinguishing 429 from authentication or verification failures.