Limites e fair use
Atualizado Aug 2026 · API v3Os limites existem para manter a API saudável para todos — o uso normal nunca lhes toca.
Rate limits
- Tráfego da API pública: por omissão 60 pedidos/minuto por cliente+utilizador.
- Além disso aplicam-se limites de infraestrutura por IP — integrações normais nunca lá chegam.
- Atingir um limite responde
429com um headerRetry-After; os headersX-Rate-Limit-*dizem-te a qualquer momento onde estás.
Fair use
Para lá dos limites rígidos por minuto existe um guia mensal suave:
3 000 pedidos/mês (lê o valor atual em direto de
GET /v3/users/me/usage como fairUse.monthlyReference). É um indicador,
não uma imposição: ultrapassá-lo muda uma cor na tua página de utilização
em my.pon.app, nada mais. Os teus números em direto (hoje, mês, por token)
também estão lá.
O pedido mais barato é o que não fazes.
Os webhooks dizem-te quando algo mudou; um fetch condicional a seguir é tudo o que precisas. Isso mantém a maioria das integrações muito abaixo do guia.Quotas de recursos
Tetos generosos contra automação desgovernada (422 QUOTA_EXCEEDED com
details.resource e details.limit):
| Recurso | Limite |
|---|---|
| Listas próprias | 200 |
| Itens ativos por lista | 5 000 (LIST_FULL) |
| Imagens | 2 000 |
| Convites abertos por lista | 50 |
| Participações em listas | 500 |
| Personal access tokens | 10 (TOKEN_LIMIT) |
| Webhooks | 5 (WEBHOOK_LIMIT) |
O envelope de erros
Todos os erros, todos os endpoints, a mesma forma:
{ "errors": [ { "code": "LIST_FULL", "message": "…", "details": { "limit": 5000 } } ] }
As respostas com sucesso são sempre { "data": …, "meta": … }. Os
caminhos de escrita são amigos da idempotência — repetir uma escrita
falhada é seguro.