Limites são contados por endpoint, por IP, por minuto — não por conta ou por chave da API, então cada servidor atrás do mesmo IP de saída compartilha um orçamento. Cada limite é independente: esgotar POST /auth não afeta GET /transactions. Onde um limite abrange dois endpoints, as requisições para qualquer um contam contra ele.
Limites#
| Endpoint | Requisições por minuto por IP |
|---|---|
POST /auth | 360 |
GET /accounts, GET /accounts/{id} | 360 |
GET /transactions, GET /transactions/{id} | 360 |
GET /investments, GET /investments/{id} | 360 |
GET /investments/{id}/transactions | 360 |
PATCH /items/{id} | 20 |
PATCH /items/{id} é dimensionado para atualizações acionadas pelo usuário. Atualizações diárias pertencem ao auto-sync, não a um loop de chamadas PATCH.
A resposta 429#
Requisições adicionais para esse endpoint continuarão falhando até que a janela de um minuto seja redefinida. Três cabeçalhos informam quanto tempo:
| Cabeçalho | Significado |
|---|---|
RateLimit-Limit | O limite para este endpoint, por minuto. |
RateLimit-Reset | Segundos até que o contador seja redefinido e o endpoint aceite requisições novamente. |
Retry-After | A dica padrão de nova tentativa. Sempre 60. |
Aguarde RateLimit-Reset segundos e tente novamente. Clientes HTTP com comportamento de nova tentativa padrão (por exemplo, got) já respeitam Retry-After em um 429.
Quando você continua atingindo um limite#
- Reutilize a chave da API por suas 2 horas em vez de chamar
POST /authpor requisição — veja AutenticaçãoAPI. - Limite o paralelismo de trabalhos em lote contra um endpoint e espaçe as chamadas.
- Procure por requisições duplicadas em operação normal.
- Se a aplicação realmente precisar de mais, entre em contato com o suporte com o caso de uso.
Leia o guia: Limites de taxa.