Rate limited

You are getting 429 rate_limited on POST /v1/ingest. The default limit is 60 requests per minute per device. If your sensor is hitting that, one of the following is true.

1 · The sensor is in a fast loop

A new firmware that does not back off on success will hammer the ingest on every loop iteration. Common with DIY ESP32 sketches missing a delay(), or ESPHome configs where interval: was misread as every loop.

Symptom: 200 OK for the first ~60 requests in a minute, then 429 for the rest of the minute, then the cycle repeats.

Fix: enforce a minimum loop interval in the device firmware. We recommend 60 s for cold-chain, 30 s for door-event, 1–5 s for energy clamp monitoring (read on, see batching below).

2 · You are batching at the wrong layer

For energy meters that read at 1 Hz, sending one request per second is both wasteful and rate-limit-blocked. Batch on the device side:

POST /v1/ingest
{
  "device": "panel1",
  "measurements": [
    { "ts": "2026-05-17T08:22:00Z", "type": "power", "value": 1240 },
    { "ts": "2026-05-17T08:22:01Z", "type": "power", "value": 1255 },
    { "ts": "2026-05-17T08:22:02Z", "type": "power", "value": 1268 },
    …up to 32 entries…
  ]
}

One HTTP request, 32 measurements, each with its own ts. The endpoint accepts up to 32 entries per request. Rate-limit budget is per request, not per measurement.

For 1 Hz sampling: batch every 30 s (30 entries), POST once. Budget is 2 req / min — well under the limit.

3 · A misbehaving retry loop

A 5xx response triggers retry in many client libraries. If the retry backoff is too tight (e.g. requests default of 0.2 s between retries), a brief outage on our side bursts into hundreds of requests per minute when the service comes back.

Recommended retry policy:

• On 5xx: retry with exponential backoff starting at 1 s, multiplying by 2, capped at 60 s, with jitter.
• On 429: respect Retry-After. Do not retry sooner.
• On 401 / 403 / 422: do not retry; the request will never succeed unchanged.

4 · Many devices behind one NAT

The rate limit is per device, not per IP — so 50 devices behind one NAT can collectively send 3000 req / min. If you are getting 429 with only one logical device, you may be sharing a device id across multiple physical sensors. Each physical sensor should have its own device id and token.

5 · You are using the wrong ingest path

If you have an ESP32 sending 60 readings / min at /v1/ingest, half of those are the same channel value. Sending the delta instead — only when the reading changes by > X % — drops volume by 80 % in typical cold-chain installs.

ESPHome supports this with a delta filter on a sensor:

sensor:
  - platform: bme280_i2c
    temperature:
      filters:
        - delta: 0.1   # report only on ≥ 0.1 °C change

For HACCP you do not want pure delta filtering (the auditor wants regular samples). Combine with a heartbeat filter:

filters:
  - delta: 0.1
  - heartbeat: 60s

This means: report on any 0.1 °C change, and at least once per 60 s regardless of change. Same compliance profile, fraction of the bandwidth.

What to do right now

If you are in production and getting 429 right now, the fastest mitigation is:

• Drop the cadence to 120 s temporarily.
• Open a ticket — for short bursts we can raise the limit on your account within 24 h, no questions asked.

The limit is there to protect the ingest pipeline from misconfigured clients, not to upsell. We do not gate "the actual product" on it.