La API forma parte del plan Enterprise. Tres límites la mantienen equilibrada para todas las cuentas:
| Límite | Cuánto | Por quién se cuenta |
|---|---|---|
| Peticiones | 60 por minuto | Cada clave de API, y cada permiso de un cliente de IA |
| Escrituras | 30 por minuto | Cada clave o permiso, dentro de sus peticiones |
| Filas leídas | 500.000 al día | Toda la cuenta: todas sus claves y permisos juntos |
El minuto es una ventana deslizante, que se cuenta igual en todos los servidores. El día es un día UTC: las filas vuelven a empezar a medianoche UTC. Las escrituras vienen con el módulo de campo, y los permisos, con la capa MCP para clientes de IA. Un permiso lee como mucho 100.000 de las filas del día de la cuenta, para que un solo cliente de IA no las gaste todas. Ninguno de estos límites afecta a las descargas de la página «Exportar» del portal, que tienen su propia cuota.
Otros dos límites cuentan las llamadas por la dirección de la que llegan, antes de buscar ninguna clave, igual en la API que en la capa MCP: uno sobre todas las peticiones de una dirección, muy por encima de lo que usan varias claves a toda velocidad, y otro sobre las claves rechazadas de una dirección, a partir del cual una clave errónea, caducada o revocada responde 429 en lugar de 401.
Cómo se cuentan las filas
Cada llamada cuenta las filas que lee, ya sea por la API, por sus feeds CSV o por la capa MCP:
- una llamada a
/releasescuenta una fila por cada semana que lista; - una llamada a una tabla cuenta las filas que ha leído, así que un
limitmás pequeño cuesta menos; - una escritura cuenta una fila, que se carga antes de ejecutarla.
Las filas se cargan después de la lectura, con un bloqueo sobre la cuenta, de modo que las llamadas simultáneas nunca se llevan a la vez las últimas filas del día. De ahí se siguen dos cosas:
- cuando se agotan las filas del día, toda llamada se rechaza antes de hacer ningún trabajo, hasta la medianoche UTC;
- una llamada que las superaría se rechaza y su respuesta se descarta, sin gastar ninguna fila;
details.remainingindica cuántas filas le quedan al día. Pide menos conlimit, o espera al día siguiente.
La página de claves («Ajustes de la cuenta» › «API») muestra las peticiones y las filas de cada clave en los últimos 7 días, para que veas cuál de tus sistemas gasta el día.
Cómo responde un límite
Una llamada rechazada responde 429 con el código RATE_LIMITED, una cabecera Retry-After con los segundos que hay que esperar y details.resetAt, el momento en que se libera la ventana, en milisegundos desde la época Unix. No vuelvas a intentarlo antes de que pase Retry-After: un reintento dentro de la ventana también se rechaza. Para las filas del día, ese momento es la siguiente medianoche UTC.
Un 503 con el código BUSY también lleva Retry-After: en ese momento se está escribiendo el trabajo de ese tipo de la cuenta, así que vuelve a intentarlo unos segundos después. Ninguna otra respuesta lleva cabeceras de contadores; la señal es el propio rechazo.
En cada llamada
Una llamada toma de una tabla como máximo las filas del límite de exportación del plan. Sin limit, /data/{kind} y todos los feeds se detienen ahí y lo indican (truncated, o la última línea del CSV), y un limit mayor responde 400. Por la capa MCP, get_data toma menos filas por llamada: la referencia del MCP da sus cifras.
El feed OData
El feed OData cuenta para las mismas peticiones y filas. Una página o un recuento de una tabla cuesta las filas que envía, las que se salta y las que cuenta. Una página o un recuento de un conjunto de datos semanal cuesta cada fila que lee, la conserve su filtro o no: un filtro sobre sus semanas, o una igualdad sobre su tienda, cadena, provincia, referencia o categoría, acota lo que lee; un filtro sobre cualquier otra columna, no. Una petición que pasaría de las filas del día se detiene, responde 429 y no cuesta ninguna. Las páginas y los recuentos de los conjuntos de datos semanales tienen además 20 peticiones por minuto por clave y 40 entre todas las claves de la cuenta, y se rechazan como cualquier otro límite.
Cómo gastar menos
- Consulta
/releasesantes de leer las tablas: una semana nueva ahí significa datos nuevos. - Lee cada tabla una vez por semana publicada, como feed CSV, en lugar de con muchas llamadas pequeñas.
- Deja que un webhook avise a tus sistemas cuando se publique una semana.
- Usa un
limitpequeño mientras desarrollas y pruebas. - Reparte las llamadas a lo largo del minuto y espacia tus reintentos.