Amberflo · Rate Limits

Amberflo Rate Limits

Amberflo does not publish per-second rate limits on its public site. The Metering API is designed for high-throughput event ingestion and supports batch ingestion to amortize request count. Plan-level event volumes (10K Startups, 500K Growth) act as monthly quotas rather than per-second throttles. Treat 429 / 503 responses as throttle signals and apply exponential backoff.

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

It captures 3 rate-limit definitions, measuring events_per_month and varies.

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

Tagged areas include Rate Limiting, Usage-Based Billing, Metering, and Amberflo.

3 Limits Throttle: 429
Rate LimitingUsage-Based BillingMeteringAmberflo

Limits

Meter event ingestion (Startups plan) account
events_per_month · month
10000
Plan-level monthly quota; overage moves the customer above the included pool.
Meter event ingestion (Growth plan) account
events_per_month · month
500000
Plan-level monthly quota; overage at $5 per additional 10,000 events.
Per-second API throughput account
varies
not publicly documented
Use batch ingestion endpoints; contact support for sustained high-volume ingest.

Policies

Batch ingestion
Use the bulk meter-events endpoint to amortize request count over many records and reduce request-rate pressure.
Exponential backoff
Retry 429 and 503 responses with exponential backoff and jitter; respect Retry-After when present.
Idempotency
Each meter event should carry a unique transactionId to allow safe retries without double-counting.
Plan-level quotas
Monthly event and billing-volume pools are quotas tied to the subscription plan; exceeding triggers overage line items rather than throttling.

Sources