El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Los límites de frecuencia deberían estar documentados, no descubrirse
Hay un tipo particular de mala mañana que empieza con un pico de solicitudes fallidas y termina con un desarrollador leyendo por primera vez la página de estado de un proveedor, intentando averiguar si los fallos se deben a una caída o a un límite que nunca supo que existía. Esa mañana es totalmente evitable, y que siga ocurriendo en todo el sector es un fallo de documentación, no de infraestructura.
Un límite de frecuencia no es un secreto. Es un hecho operativo de un sistema, igual que un tamaño máximo de solicitud o un método HTTP admitido, y su lugar es el mismo: por escrito, antes de que nadie lo alcance. Publicamos los nuestros en la documentación de límites de frecuencia, junto a las páginas de autenticación y de errores, para que las cifras con las que un desarrollador tiene que planificar estén disponibles antes de escribir la primera línea de código de integración, no después de la primera tarde con aspecto de caída.
Sin embargo, la documentación por sí sola no basta, porque los límites pueden depender del plan que tengas, y un documento queda desactualizado en cuanto cambia el estado de tu cuenta. Por eso cada respuesta incluye también cabeceras de cuota en tiempo real: tu límite, cuánto has usado, cuánta cuota gratuita queda, cuánto se ha usado de la cuota compartida de tu red, tu crédito prepago restante y cuándo se reinicia la cuota. No tienes que cotejar un documento con tu panel para saber en qué punto estás. La respuesta viaja junto con la propia respuesta de la API, en cada llamada.
Algunos proveedores tratan los límites publicados como una debilidad competitiva que hay que ocultar, con la teoría de que una cifra visible invita a los clientes a negociarla a la baja o a compararla con la de un competidor. Creemos que ese instinto va al revés. Un límite que nadie puede ver no protege mejor la infraestructura del proveedor. Solo significa que la primera vez que un cliente conoce la cifra real es cuando ya la ha superado, en el peor momento posible para un producto en crecimiento, delante de sus propios usuarios.
Documentar los límites desde el principio también impone al proveedor una disciplina de diseño. Si un límite de frecuencia se va a publicar, tiene que ser una cifra real que alguien esté dispuesto a respaldar, no un umbral interno impreciso que se ajusta en silencio cada vez que resulta incómodo. Poner la cifra por escrito e incluirla en las cabeceras de respuesta de cada llamada significa que el límite tiene que ser de verdad el límite, de forma constante, que es exactamente la propiedad que un desarrollador necesita que tenga.
Descubrir un límite de frecuencia a través de una solicitud fallida en producción no es un rito de iniciación. Es una señal de que la documentación no hizo su trabajo. La nuestra pretende que esa mala mañana sea algo que lees que le ocurre a otra persona, no algo que te ocurre a ti.