Toda petición (salvo las rutas /public/*) se autentica con una API key personal que comienza con sk_. La envías en el header x-api-key o como Bearer token, y con ella la plataforma mide tu consumo mensual según el plan contratado. Puedes crear y rotar keys desde el panel en cualquier momento.
Dónde va la API key
La API key te identifica como cliente y viaja en el header `x-api-key` de cada petición. No la pongas en la URL ni en el cuerpo: las URLs quedan registradas en logs, proxies y analítica, así que una key en la query string es una key filtrada.
Si tu cliente es una app web, la key nunca debe llegar al navegador. Las llamadas salen desde tu backend, y el frontend habla con tu backend.
Validar la key antes de integrar
Antes de escribir la integración completa, haz una sola petición a GET /validate. Te dice si la key está activa y a qué cuenta pertenece. Cuando algo deja de funcionar, es el primer descarte: separa un problema de credenciales de un problema de datos.
Rate limit y qué hacer con un 429
El límite es de 1.000 peticiones por minuto por key. Una integración que consulta cada guía por separado cada pocos segundos se acerca a ese techo en cuanto suben los pedidos. Para cambios de estado usa webhooks y deja el polling para consultas puntuales.
Si recibes un 429, no reintentes en bucle: espera un intervalo creciente entre intentos y reparte el trabajo. Un bucle de reintentos sin espera consume la cuota que queda.
Buenas prácticas para producción
Guarda la key en variables de entorno, nunca en el repositorio. Usa una key distinta para pruebas y para producción, así puedes rotar una sin afectar a la otra, y si sospechas una filtración pide el reemplazo: rotar sale más barato que descubrir consumo ajeno.