Limits

No limit here is a surprise: the published numbers are frozen by a contract test, precisely so that whoever integrated against a published number does not start taking 429s with no explanation. This page is the complete list.

1. Requests per second, per application

Each route class has its own bucket. Exhausting the read bucket does not affect the send bucket.

Device routes have no per-second, per-application cap. Registration, updates, receipts, In-App and the Firebase parameters are limited by a different path: the per-origin cap in section 2 and the 50,000 registrations per hour per application cap in section 4. If you are sizing a bulk registration load, those are the two numbers to plan against.

Repeating a read costs no quota

Before the cap is charged, a read is served from a 1-second cache. If your integration asks about the same push twice within the same second, the second answer comes from the cache, does not count against the bucket and never touches the database.

This is deliberate: an integration tracking thousands of pushes per cycle has every right to ask often, and data one second old has not changed. The cap then protects what actually costs — the database round trip. Who hits 429 is whoever asks for different things too fast.

The bucket survives losing the shared cache

With the shared cache up, the count is global per application. If it goes down, the cap still exists, just per service process — degraded, never switched off.

---

2. Requests per minute, per origin

The public routes called by the device are limited per origin:

The edge is deliberately looser than the service: nobody who passes the service is blocked by the edge. It exists as a second line, in case traffic grows faster than the process can refuse it.

Refused requests count too — hammering does not buy attempts.

{
  "errors": ["limite de requisições excedido"],
  "explain": {
    "causa": "mais de 120 req/min a partir do mesmo IP (203.0.113.10)",
    "como_corrigir": "aguarde a janela de 60 s e honre o Retry-After",
    "request_id": "0198f0b2-6e31-7a4c-9f10-2c9a1d4e7b55"
  }
}

The text arrives in Portuguese, exactly as shown. In English: “more than 120 req/min from the same IP” and “wait out the 60 s window and honour Retry-After”.

About the Retry-After header

Be precise when you program your backoff, because the two 429s are not the same:

• the per-origin 429 (device routes) does emit Retry-After: 60;
• the per-class 429 (send, read, export) carries the wait in the explain.como_corrigir text (“aguarde 1s e tente de novo” — wait 1 s and try again) and, in this version, does not add the header.

The safe rule for your client: read Retry-After when it is there; when it is not, honour the value quoted in explain.como_corrigir. Never retry in a tight loop.

---

3. Body size

The two caps differ on purpose. 16 KB is the body a device sends (registration, receipt) and it has no reason to grow. The send route carries a recipient list: at the maximum of 2,000 identifiers the request is around 80 KB, and 256 KB leaves three times the headroom over the largest valid batch.

The cap is applied in two stages: if the declared Content-Length already exceeds it, the response goes out without reading the body; if the actual body exceeds it (chunked, or a lying Content-Length), it is cut off while buffering. In both cases the answer is a 413 in the standard envelope, with the limit named — never a bare 413 with no explanation.

{
  "errors": ["corpo acima do limite da rota"],
  "explain": {
    "causa": "corpo excede o limite da rota (256 KB)",
    "como_corrigir": "reduza o corpo da requisição e reenvie",
    "request_id": "0198f0b2-6e31-7a4c-9f10-2c9a1d4e7b55"
  }
}

---

4. Product limits

Everything below returns a named 400 or 422, never a silent truncation.

Sending

The payload limit deserves an explanation, because it surprises people the most. The 3,891-byte budget is measured on the final payload, including the 96 bytes the server still injects at send time (pm_msg_id and pm_rcpt — the trail that makes delivery and click receipts possible). If the front door ignored those bytes, a message right at the limit would pass here and die with a provider error — the push would vanish silently. The check runs before touching the database, and the 422 carries the exact count.

Devices

Base export

The export 429 teaches the right path: “the previous file is still valid for 72 h — download the URL you already received instead of asking for another”.

Idempotency

Thirty days is not decoration: anyone with their own queue reprocesses days later, and a promise that “the same key never fires twice” valid for a single day would not be a promise, it would be luck.

Webhooks

Details in Webhooks.

In-App messages

The In-App channel’s limits (blocks per campaign, event batch size, campaigns per session package, package validity and the minimum interval between two messages) live next to the contract that explains them, in In-App messages.

---

5. The commercial limit: the free plan allowance

This one is not a technical cap, and it is the only limit on this page that refuses the whole send.

The free plan delivers within a monthly active user allowance. Above it, POST /api/v1/notifications answers 422 and nothing is sent — not even to part of the list. Truncating would be worse: you would see “campaign sent”, and part of your base simply would not receive it, with no signal at all.

The response carries the numbers so you can act without opening a ticket:

{
  "errors": ["plano Free atende até 1000 usuários ativos no mês — sua conta está com 1240"],
  "explain": {
    "causa": "o plano Free entrega dentro da franquia de 1000 usuários ativos no mês, e em 2026-08 a sua conta registrou 1240; acima da franquia o envio é recusado INTEIRO — entregar só para uma parte da base, escolhida por ordem de consulta, seria sumir com o resto em silêncio",
    "como_corrigir": "mude para o Premium (USD 0.005 por usuário ativo acima da franquia, sem mensalidade) e o envio volta na hora — os 1000 primeiros usuários ativos continuam gratuitos nos dois planos",
    "plano": "free",
    "mau": 1240,
    "mau_gratis": 1000,
    "mes": "2026-08",
    "moeda": "USD",
    "preco_por_mau": "0.005",
    "medido_ha_s": 12
  }
}

The prose arrives in Portuguese, exactly as printed above. In English, it reads: “the free plan delivers within an allowance of 1000 monthly active users, and in 2026-08 your account recorded 1240; above the allowance the send is refused ENTIRELY”, and the fix is “move to the paid plan and sending resumes immediately — the first 1000 monthly active users stay free on both plans”. Branch your code on explain.mau, explain.mau_gratis and explain.plano, never on the sentence.

Three honest notes about that number:

1. It is not real time. Counting scans the whole base, so it is recomputed periodically in the background — at most once a minute — and the medido_ha_s field tells you the age of the number you are arguing with.
2. It is a brake, not an invoice. Between one measurement and the next, an account can go past the allowance for a few minutes and keep delivering. Billing is settled by the invoice, measured over the whole month.
3. Infrastructure failure never blocks anyone. With no database, no usable measurement, or a measurement that is too old (over 600 seconds), the check lets the send through. A customer who stops delivering because an internal query failed is a bigger loss than under-billing — and that is a written decision, not an accident.

And the retry rule: 422 belongs to the “fix the request, do not repeat” family. Here the fix is not in your JSON, it is in the plan — repeating the call changes nothing.

---

See also