Aurora Solar · Rate Limits

Aurora Solar Rate Limits

Aurora publishes a default API rate limit of 90 requests per minute. Individual endpoints may enforce their own limits and are documented accordingly. When a limit is exceeded, Aurora returns HTTP 429 and clients should inspect the response body and/or the `Retry-After` response header to know when the next call is allowed. Aurora explicitly recommends webhooks over polling to stay within limits, and points high-volume customers to their account representative for workflows tailored to their needs. Many design operations (AutoDesigner, irradiance analysis, performance simulation, plan-set and utility-bill jobs) are asynchronous - submit-then-poll or webhook - which naturally reduces request pressure.

Aurora Solar Rate Limits is the machine-readable rate-limit profile for Aurora Solar on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring requests and jobs.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Solar, Solar Design, PV, Rate Limiting, and Quotas.

3 Limits Throttle: 429
SolarSolar DesignPVRate LimitingQuotas

Limits

Default API Requests tenant
requests
90 per minute
Documented default rate limit across the API. Exceeding it returns 429.
Per-Endpoint Limits endpoint
requests
varies
Individual endpoints may define their own limits, documented on the endpoint reference.
Asynchronous Jobs tenant
jobs
not published
Design generation, irradiance analysis, performance simulation, plan sets, and utility-bill uploads are async; poll status or subscribe to webhooks rather than tight-loop polling.

Policies

Retry-After
On 429, honor the Retry-After response header (and/or response body) to time the next request.
Prefer Webhooks
Aurora recommends subscribing to webhooks instead of polling to stay within rate limits.
Backoff Strategy
Implement exponential backoff with jitter on 429 and 5xx responses.

Sources