Uso y Cuotas
Vincent Depassier · 30 de agosto de 2026
El plan de tu workspace incluye una cantidad de llamadas al API gateway por mes de facturación. Esta página es sobre qué cuenta, qué pasa cuando llegás al límite, y cómo necesitar menos.
Qué cuenta
Todo request que procesa el gateway: consultas y mutaciones PraxQL, llamadas a endpoints, llamadas a herramientas MCP, autenticación de usuarios finales, descargas de archivos.
Dos cosas no cuentan:
Las corridas del Playground. Probar una consulta en el portal es gratis y no se mide.
Lo rechazado antes de que el gateway procesara. Un request que falla la autenticación queda registrado, pero no hizo trabajo.
Leer tu consumo
GET /{workspaceId}/usage devuelve la foto actual, y el portal muestra lo mismo:
Campo | Significado |
| Llamadas hechas este mes de facturación |
| El límite mensual del plan — `-1` es ilimitado |
| Qué pasa al llegar: |
| Precio del excedente por cada 1.000 llamadas, en USD |
| Llamadas hechas por encima del límite este período |
| Cargo proyectado por excedente del mes |
projectedCost es el campo que conviene poner en un dashboard. Convierte "estamos usando mucha API" en un número al que alguien puede reaccionar antes de que lo haga la factura.
Qué pasa al llegar al límite
Un solo ajuste, dos resultados muy distintos.
Block — los requests se rechazan con 429 una vez agotada la cuota. Tu costo no puede superar el plan, y tus integraciones se detienen. Correcto para herramientas internas, un workspace de staging, o cualquier cosa donde una factura sorpresa sea peor que una caída sorpresa.
Pago por uso — los requests siguen funcionando y el exceso se factura como excedente. Tus integraciones no se pueden caer por un pico de tráfico, y tu factura puede crecer sin que nadie la apruebe. Correcto para cualquier cosa de cara al cliente.
No hay una tercera opción que sea las dos, así que elegí preguntándote qué falla preferirías tener que explicar: una caída, o una factura.
Un bucle de reintentos es el caso que duele con cualquiera de los dos ajustes. Con Block consume la cuota restante en minutos y tumba todo lo demás; con pago por uso factura cada intento. Por eso el filtro de
429en la pestaña Logs conviene revisarlo cada tanto y no solo cuando algo se rompe.
Usar menos llamadas
Tres palancas, en el orden en que suelen rendir.
1. Pedir más por llamada
PraxQL se diseñó para que un request responda lo que en REST necesitaría varios. Un cliente con sus pedidos y los ítems de cada pedido es una consulta con relaciones anidadas, no una más N más N×M. Si tu conteo de llamadas es alto y tu conteo de pantallas no, la razón suele ser esta.
Las relaciones van por lotes, así que anidar cuesta una consulta extra por nivel — no una por fila. Ver Relaciones.
2. Cachear en la credencial
Una credencial puede cachear sus propias respuestas:
Modo | Comportamiento |
| Cada request se ejecuta — el default |
| Reusa por |
| Reusa hasta que se escriba en la tabla subyacente |
| Se invalida por escrituras, con el TTL como techo |
WriteInvalidated es el interesante: no puede servir datos viejos después de una escritura que hizo tu propio workspace. Su punto ciego son los datos cambiados por algo que el gateway no vio, que es justo lo que cubre Hybrid.
Como el caché es por credencial, una key pública con mucha lectura puede cachear agresivamente mientras tu key de backend no cachea nada — la misma consulta, dos políticas distintas.
Un caché se puede purgar para una credencial, o para todas las credenciales que tocan una tabla dada, desde el portal.
3. Cachear en el endpoint
Los endpoints tienen su propio caché con los mismos modos, más dos cosas que el de credencial no tiene: el cuerpo del request siempre forma parte de la clave, y quien mande If-None-Match recibe un 304 sin payload alguno.
Nunca caches un endpoint que escribe. Un efecto secundario cacheado significa que el segundo llamador recibe la respuesta del primero y su escritura nunca ocurre.
Antes de subir el plan
Revisá los Logs primero. El consumo alto suele ser una de estas, y ninguna se arregla con una cuota más grande:
Un cliente haciendo polling por temporizador que podría estar escuchando el Event Bus.
Un bucle de reintentos contra un endpoint que viene fallando hace días.
Una pantalla emitiendo una consulta por ítem de lista en vez de una consulta con una relación.
Un cron corriendo mucho más seguido de lo que cambian los datos que lee.
Filtrá el log por credencial, ordená por cantidad, y la respuesta suele ser la primera fila.
Siguiente
Logs — dónde están las llamadas detrás de estos números.
Credenciales y Principales — dónde se configura el caché por credencial.