Rate Limit
O que é o Rate Limit?
É um limite que define o quanto alguma ação consegue ser executada dentro de um espaço de tempo.
Como funciona o rate limit?
O Rate Limit determina quantas requisições um usuário pode realizar em um período determinado de tempo para uma das rotas de nossa aplicação. Por exemplo, um usuário não pode executar mais do que 10 requisições no período de um segundo e quando a cota limite de requisições neste período for excedida, o usuário irá receber um código de erro na resposta, informando que o limite foi excedido.
No Pagar.me, caso em alguma situação seja ultrapassado o limite de requisições em alguma de nossas rotas, será retornado o código de erro HTTP 429 e a mensagem “Too Many Requests” ou a mensagem “Rate limit exceeded” por nossa API.
Quais são os limites de cada rota da API do Pagar.me?
O Pagar.Me verifica o limite de requisição para suas rotas considerando duas unidades de tempo:
- Minuto
- Segundo
Sendo assim, é possível que um bloqueio ocorra para determinado conjunto de requisições de acordo com a quantidade de envios dentro de mais de um período de tempo.
Rota | Método | Requisições por segundo | Requisições por minuto |
---|---|---|---|
/:model/:model_id/events | GET | 4 | Não Aplicado |
/:model/:model_id/operations | GET | 3 | Não Aplicado |
/:model/:model_id/postbacks | GET | 3 | Não Aplicado |
/:model/:model_id/postbacks/:id/redeliver | POST | 3 | Não Aplicado |
/balance | GET | 4 | 300 |
/balance/operations | GET | 6 | Não Aplicado |
/bank_accounts | POST | 3 | Não Aplicado |
/bank_accounts | GET | 2 | Não Aplicado |
/boletos/:id | GET | 30 | Não Aplicado |
/bulk | POST | 3 | Não Aplicado |
/cards | GET | 8 | 400 |
/companies | POST | 1 | Não Aplicado |
/company | GET | 12 | 700 |
/customers/:id | GET | 5 | Não Aplicado |
/orders | GET | 10 | Não Aplicado |
/orders/:id | GET | 3 | Não Aplicado |
/payables | GET | 12 | 700 |
/payables/:id | GET | 10 | Não Aplicado |
/payment_links/:id | GET | 15 | Não Aplicado |
/recipient/:id | PUT | 3 | Não Aplicado |
/recipients | POST | 5 | 300 |
/recipients/:id | GET | 5 | Não Aplicado |
/recipients/:id/balance | GET | 5 | 300 |
/recipients/:recipient_id/balance/operations | GET | 6 | 300 |
/recipients/:recipient_id/balance/operations.(csv|xlsx) | GET | 5 | Não Aplicado |
/recipients/:recipient_id/bulk_anticipations/limits | GET | 10 | Não Aplicado |
/search | GET | 7 | 400 |
/subscriptions | GET | 5 | 300 |
/subscriptions/:id | GET | 13 | Não Aplicado |
/subscriptions(|.:format) | GET | 5 | Não Aplicado |
/subscriptions/:id/transactions | GET | 13 | Não Aplicado |
/terminal/aids | GET | 10 | Não Aplicado |
/terminal/capks | GET | 10 | Não Aplicado |
/transactions(|.:format) | GET | 12 | 700 |
/transactions/:id | GET | 10 | Não Aplicado |
/transactions/:transaction_id/payables | GET | 10 | Não Aplicado |
/transactions/calculate_installments_amount | GET | 100 | Não Aplicado |
/transactions/:transaction_id/send_receipt | POST | 10 | Não Aplicado |
/transfers | POST | 3 | Não Aplicado |
/transfers/:id | GET | 5 | Não Aplicado |
/transfers/:id/receipt | POST | 1 | Não Aplicado |
/transfers/limits | GET | 3 | Não Aplicado |
/zipcodes/:id | GET | 30 | Não Aplicado |
Para rotas de GET que não estão listadas nesta tabela, aplica-se o limite padrão de 4 requisições por segundo.
Para rotas de POST e PUT não listadas na tabela, não se aplica nenhum rate limit.
Alteração dos limites
O Pagar.me pode alterar o limite das rotas de acordo com a necessidade de mantermos a qualidade em nossos serviços. Você pode checar sempre que necessário estes limites nesta página da documentação.
Como adaptar meu sistema para atender a esse limite?
É possível adaptar suas diretrizes de envio de requisições, a partir de cabeçalhos (headers) para que vocês tenham um melhor controle de sua integração.
Para isso disponibilizamos as seguintes informações no header de cada resposta da API:
X-RateLimit-Limit
X-RateLimit-Remaining
X-RateLimit-Reset
Retry-After
Campo no Header | Descrição |
---|---|
X-RateLimit-Limit | indica a cota limite em unidades de requisições em uma janela de tempo |
X-RateLimit-Remaining | indica a cota restante em unidades de requisições dentro de uma janela de tempo. |
X-RateLimit-Reset | indica o horário no padrão epoch time que ocorrerá o reset da contagem da cota limite de unidades de requisições dentro da janela de tempo atual, portanto a partir deste horário, uma nova cota de requisições estará disponível. |
Retry-After | indica os segundos para que seja realizado o reset da cota limite dentro de determinada janela de tempo. |
Como exemplo, se for retornado os headers no horário Mon, 05 Aug 2019 09:27:00 GMT em uma requisição que ocorreu o erro HTTP 429:
Retry-After: 5
X-RateLimit-Reset: 1564997225
X-RateLimit-Limit: 100
X-Ratelimit-Remaining: 0
Significa que a cota em unidades de requisições desta rota, possui um limite de 100 requisições dentro de uma janela de tempo pré-definida e já foram realizadas as 100 requisições dentro deste período e que, em 5 segundos ( Mon, 05 Aug 2019 09:27:05 GMT ), este limite será resetado e uma nova cota de requisições será disponibilizada.
Existem diversas bibliotecas disponíveis para clientes HTTP que podem auxiliar nas definições e gerenciamento de políticas de envio de requisições, como a axios-rate-limit para o cliente Axios ou outras bibliotecas como o Limiter para Ruby ou limiter para node.js.
Outro solução que pode auxiliar o gerenciamento de requisições é aplicar um algoritmo de backoff exponencial em vez de uma lógica de nova tentativa. Esse algoritmo fornece melhor controle de fluxo para tais cenários.
O backoff exponencial aguardará tempos progressivamente mais longos entre as novas tentativas de solicitação assim atendendo aos limites de cada rota.
Abaixo apresentamos um exemplo de código de envio de retentativa de uma requisição utilizando o algoritmo de backoff exponencial em cada tentativa.
algoritmo BackoffExponencial
início
inteiro numeroDeTentativas <- 0
logico sistemaDeveRetentar <- falso
constante inteiro numeroMaximoDeRetentativas <- 5
faça
se (numeroDeTentativas > 0)
aguarde por 2^numeroDeTentativas x 200 milissegundos antes de continuar
respostaDaAPIPagarme <- Resultado da Requisição
se (respostaDaAPIPagarme == "429 - rate limit excedido")
sistemaDeveRetentar <- verdadeiro
senão
sistemaDeveRetentar <- falso
numeroDeTentativas <- numeroDeTentativas + 1
enquanto (sistemaDeveRetentar E numeroDeTentativas < numeroMaximoDeRetentativas)
fim
Quando esse limite entra em vigor?
No dia 05/07, vamos mudar os limites relacionados ao “Rate Limit” em diversas rotas de nossa API.
Updated about 2 years ago