Limites de requisições
O WhatIsUp usa um limitador token-bucket, escopado por chave de API.
Padrões
- 60 de burst. Um bucket cheio guarda 60 tokens. Gaste-os tão rápido quanto quiser.
- 1 requisição por segundo sustentada. O bucket reabastece a 1 token / seg.
Existem ajustes específicos por plano; os headers abaixo sempre refletem seus limites reais.
Headers de resposta
Toda resposta carrega:
| Header | Significado |
|---|---|
X-RateLimit-Limit | Capacidade do bucket. |
X-RateLimit-Remaining | Tokens restantes depois que esta requisição foi contabilizada. |
X-RateLimit-Reset | Timestamp Unix (segundos) de quando o bucket ficará cheio de novo. |
No 429 Too Many Requests, você também recebe:
| Header | Significado |
|---|---|
Retry-After | Segundos a esperar antes da próxima requisição. Respeite isso. |
O corpo usa o envelope padrão com code: "rate_limited".
Lendo os limites sem consumir
GET /v1/limits retorna sua folga atual em cada bucket
(mensagens de saída, entregas de webhook, etc.) sem gastar um token.
Útil a partir de um dashboard antes de um burst.
Padrão de backoff
async function callApi(url, init) {
for (let attempt = 0; attempt < 5; attempt++) {
const res = await fetch(url, init);
if (res.status !== 429) return res;
const wait = Number(res.headers.get('Retry-After') ?? 1) * 1000;
await new Promise((r) => setTimeout(r, wait + Math.random() * 250));
}
throw new Error('Rate limited after 5 retries');
}Não use backoff exponencial contra 429 — o Retry-After é autoritativo
e respeita a taxa de reabastecimento com exatidão. Reserve o backoff exponencial
para 5xx transitórios.
O que conta como uma requisição
Uma requisição HTTP = um token, independentemente do tamanho do payload. As tentativas de entrega de webhook partem de nós, então não contam contra seu limite de entrada.
Precisa de mais?
Use o formulário de suporte (POST /v1/support/tickets) ou mande um email para hello@whatisup.dev. Limites mais altos fazem parte do plano Pro e são sob medida no Scale.