Tema: rate-limiting
-
Paginação e chaves de idempotência na API da Stripe: starting_after, has_more e a janela de 24 horas
Os endpoints de listagem da v1 da Stripe paginam com os parâmetros de cursor mutuamente exclusivos starting_after/ending_before (limit de 1 a 100, padrão 10) e o indicador has_more, e as bibliotecas cliente trazem auxiliares de auto-paginação para percorrer todas as páginas. Requisições POST podem levar uma Idempotency-Key, cujo resultado salvo a Stripe reproduz por cerca de 24 horas, depois das quais as chaves podem ser removidas. Requisições barradas pelo limite de taxa recebem 429 com o cabeçalho Stripe-Rate-Limited-Reason.
-
Seguir o @odata.nextLink do Microsoft Graph e lidar com o throttling 429 e os limites de batch
O Microsoft Graph pagina coleções grandes por meio de uma URL @odata.nextLink, que deve ser seguida como token opaco, sem interpretá-la nem reconstruí-la. Ele aceita tamanhos de página definidos pelo cliente com $top, aplica throttling com HTTP 429 e cabeçalho Retry-After, e limita cada requisição em lote JSON a 20 sub-requisições individuais.
-
Paginação e erros de cota nas APIs do Google: pageToken, 403 rateLimitExceeded e 429
As APIs do Google Workspace, como Calendar e Drive, paginam com o par pageToken/nextPageToken e com maxResults (Calendar) ou pageSize (Drive). O Drive sinaliza sobrecarga de duas formas: HTTP 403 com reason rateLimitExceeded ou userRateLimitExceeded, ou HTTP 429 com reason rateLimitExceeded. A documentação trata ambos como casos para repetir a requisição com backoff exponencial, ao contrário de outros motivos de 403.
-
Paginação da API REST do GitHub e leitura dos cabeçalhos de limite de taxa primário e secundário
A API REST do GitHub pagina por meio de um cabeçalho link com URLs rel="next"/"last" e um parâmetro per_page limitado a 100 na maioria dos endpoints. Os limites primários aparecem em x-ratelimit-limit/remaining/used/reset/resource, ambos os tipos de limite respondem com 403 ou 429 (os secundários às vezes com retry-after), e um GET condicional autorizado que retorna 304 não conta para o limite primário.
-
Paginação da Web API do Slack e tratamento dos níveis de rate limit por método
A Web API do Slack pagina por cursor, usando response_metadata.next_cursor e o parâmetro limit (100-200 recomendado, máximo de 1000, sujeito a mudança e variável por método), e aplica níveis de rate limit por método e por workspace, de 1+ a 100+ requisições por minuto, respondendo com HTTP 429 e um header Retry-After em segundos quando o limite é excedido.
-
RateLimit e RateLimit-Policy versus X-RateLimit-*: como ler os cabeçalhos de cota que uma API envia
Um Internet-Draft do IETF (draft-ietf-httpapi-ratelimit-headers-11, maio de 2026) propõe os campos RateLimit e RateLimit-Policy (por exemplo, RateLimit: "default";r=50;t=30) para informar a cota antes de um 429, mas continua sendo um rascunho. A maioria das APIs hoje envia cabeçalhos próprios no estilo x-ratelimit-limit/-remaining/-reset ou nada além de Retry-After, que o RFC 9110 define (segundos ou HTTP-date) e o RFC 6585 permite em respostas 429.
Legível por máquina: JSON