Brushfire · Rate Limits

Brushfire Rate Limits

The Brushfire API enforces rate limiting and returns HTTP 429 Too Many Requests when a caller exceeds the allowed number of requests. The developer portal instructs callers to read the X-Rate-Limit-Limit, X-Rate-Limit-Remaining, and X-Rate-Limit-Reset response headers (and the response body) before retrying. The specific numeric request quota per App Key is not published; the mechanism and headers are documented but the exact ceiling is disclosed only through the live headers on your own account.

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

It captures 1 rate-limit definition, measuring requests.

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

Tagged areas include Event Ticketing, Registration, Rate Limiting, and Quotas.

1 Limits Throttle: 429
Event TicketingRegistrationRate LimitingQuotas

Limits

API Requests appKey
requests
not published (surfaced via X-Rate-Limit-* headers)
Exceeding the allowance returns 429 Too Many Requests. Read X-Rate-Limit-Limit, X-Rate-Limit-Remaining, and X-Rate-Limit-Reset to observe the live ceiling and reset window for your App Key.

Policies

Versioning
Requests must specify an API version via the api-version request header (for example, 2025-07-22); a missing version returns 412 Precondition Failed.
Backoff Strategy
On a 429 response, stop issuing requests until X-Rate-Limit-Reset, and apply exponential backoff with jitter rather than retrying immediately.
Authentication
Every request must include the App Key in the Authorization header; unauthenticated requests are rejected before rate-limit accounting applies.

Sources