Tema: rate-limiting
-
Paginación y claves de idempotencia en la API de Stripe: starting_after, has_more y la ventana de 24 horas
Los endpoints de listado de la API v1 de Stripe paginan con los parámetros de cursor mutuamente excluyentes starting_after/ending_before (limit de 1 a 100, por defecto 10) y un indicador has_more; las bibliotecas cliente incluyen auxiliares de autopaginación para recorrer todas las páginas. Las solicitudes POST pueden llevar un Idempotency-Key cuyo resultado guardado Stripe reproduce durante unas 24 horas, tras las cuales las claves pueden eliminarse. Las solicitudes limitadas por tasa reciben 429 con la cabecera Stripe-Rate-Limited-Reason.
-
Seguir @odata.nextLink en Microsoft Graph y gestionar el throttling 429 y los límites de lotes
Microsoft Graph pagina las colecciones grandes mediante una URL @odata.nextLink que debe seguirse como token opaco, sin analizarla ni reconstruirla. Admite tamaños de página definidos por el cliente con $top, limita las solicitudes con HTTP 429 y un encabezado Retry-After, y acepta como máximo 20 subsolicitudes por lote JSON.
-
Paginación y errores de cuota en las API de Google: pageToken, 403 rateLimitExceeded y 429
Las API de Google Workspace, como Calendar y Drive, paginan con el par pageToken/nextPageToken junto con maxResults (Calendar) o pageSize (Drive). Drive señala la sobrecarga de dos formas: HTTP 403 con el motivo rateLimitExceeded o userRateLimitExceeded, o HTTP 429 con el motivo rateLimitExceeded. La documentación indica reintentar con retroceso exponencial en ambos casos, a diferencia de otros motivos de 403.
-
Paginación de la API REST de GitHub y lectura de sus cabeceras de límite de tasa primario y secundario
La API REST de GitHub pagina mediante una cabecera link con URL rel="next"/"last" y un parámetro per_page limitado a 100 en la mayoría de los endpoints. Los límites primarios se informan en x-ratelimit-limit/remaining/used/reset/resource, tanto los primarios como los secundarios responden con 403 o 429 (los secundarios a veces con retry-after), y un GET condicional autorizado que devuelve 304 no cuenta para el límite primario.
-
Paginación de la Web API de Slack y gestión de sus niveles de límite de frecuencia por método
La Web API de Slack pagina mediante cursores con response_metadata.next_cursor y el parámetro limit (se recomiendan 100-200; el máximo es 1000, sujeto a cambios y variable según el método), y aplica niveles de límite de frecuencia por método y por espacio de trabajo, de 1+ a 100+ solicitudes por minuto. Al superarlos devuelve HTTP 429 con una cabecera Retry-After en segundos.
-
RateLimit y RateLimit-Policy frente a X-RateLimit-*: cómo leer las cabeceras de cuota que envíe una API
Un Internet-Draft del IETF (draft-ietf-httpapi-ratelimit-headers-11, mayo de 2026) propone los campos RateLimit y RateLimit-Policy (p. ej. RateLimit: "default";r=50;t=30) para anunciar la cuota antes de un 429, pero sigue siendo un borrador. La mayoría de las API actuales envían sus propias cabeceras del tipo x-ratelimit-limit/-remaining/-reset o nada más que Retry-After, que define RFC 9110 (segundos o una HTTP-date) y que RFC 6585 permite en un 429.
Legible por máquina: JSON