API e integración
Límite de peticiones de la API
Actualizado el por el equipo editorial de PanelCompare
Límite de peticiones de la API: ¿por qué le importa al comprador?
En esta API no se ve la diferencia entre “limitado” y “roto”, y eso es un problema operativo real. Los errores ya vuelven como HTTP 200 con un objeto error y no como códigos de estado, así que no hay un 429 ante el que frenar ni un Retry-After que respetar. Un cliente que choca con un tope no documentado ve el mismo fallo genérico que vería con una clave incorrecta o un servicio desactivado, y el reflejo habitual —reintentar con más fuerza— lo empeora.
De ahí sale el patrón defensivo. Agrupa al máximo usando la forma de status para 100 ID, guarda en caché la respuesta services en lugar de descargar el catálogo entero en cada pedido, espera de forma exponencial ante cualquier error repetido sea cual sea su texto, y trata una racha repentina de errores idénticos como un posible tope y no como una interrupción. Nada en la documentación te confirmará cuál fue.
Límite de peticiones de la API: ¿cómo aparece en una lista de precios?
Casi ningún panel lo documenta, así que se descubre en lugar de leerse. Cuando un panel lo publica, aparece en la página de la API como una frase y no como un campo.
Las capas de comparación por encima de los paneles tienen sus propios límites visibles, lo que ilustra bien la forma: un índice de la competencia indica en la propia página que el plan gratuito abre 10 páginas de 200 filas y que un plan de pago permite 100 búsquedas por hora y 100 páginas (observado en smmdir.com, análisis de la competencia de PanelCompare, 2026-09-06).
¿Crees que esta definición es incorrecta?
En este mercado, la terminología la fijan los paneles que la usan, y cambia. Si un panel usa “límite de peticiones de la API” para referirse a algo distinto de lo que se explica aquí, envíanos la oferta y corregiremos la definición o registraremos la variante. El procedimiento está en la página sobre nosotros.