Límites

Connect tiene pocos límites, y esta página los junta todos. Los números que leas aquí salen del código que los aplica; cuando un tope depende del plan y no de una constante, la prosa lo dice y el valor vigente está en el dashboard, en connect.emisso.ai/billing.

Límites de petición

Cuerpo de la petición: 256 KB. Aplica a toda la superficie (/v1/tools/{id}/execute y las rutas de control). Se valida el Content-Length declarado y además se lee el cuerpo con tope, así que un header mentiroso no lo evade. Al excederlo la respuesta es 413 payload_too_large.

Emisión de enlaces de conexión: 60 por hora por organización. Es el tope de POST /v1/connect_sessions, el que acota la emisión masiva de páginas con la marca de Connect. Pasado el tope, la respuesta es 429 rate_limited con un header Retry-After en segundos.

Carril agente: 5 enlaces por hora por actor. La tool conexiones.enlace.crear tiene un tope propio encima del de organización. Una conversación real necesita uno a tres enlaces; el tope deja margen para un reintento y acota lo que puede emitir un agente con el prompt comprometido.

Sincronizaciones

El sistema externo (el portal del SII, el banco) es el recurso escaso, y los topes de esta sección existen para no quemarlo:

• Candado por conexión. Cada conexión admite una sola operación contra su sistema a la vez. Si el candado está tomado, la respuesta es 409 connection_busy; es reintentable y el candado se suelta solo.
• Un trabajo activo por conexión y período. Encolar un período que ya tiene un trabajo en cola o corriendo devuelve 409 connection_sync_in_progress. Sondea el trabajo en vuelo en lugar de encolar otro: puede que ya haya datos.
• Cola de pendientes: 50 trabajos por organización (encolados más corriendo), y hasta 24 períodos por petición de backfill. Superar cualquiera de los dos responde 429 too_many_pending; deja terminar lo que corre y reintenta.
• Techo por trabajo: 120 segundos. Es el presupuesto de ejecución de una sincronización. Para rangos largos, la vía es asíncrona: POST /v1/connections/{conn}/syncs responde 202 con los job_ids, y el avance se sondea en GET /v1/syncs/{id} o llega por webhook.

Las cadencias programadas disponibles por conexión son off, daily, 12h y 6h. Se configuran en los ajustes de cada conexión del dashboard; la sincronización a pedido convive con la programada bajo los mismos candados.

Medición y plan

La fuente de la medición es la bitácora: cada llamada deja exactamente una fila, con sus billable_units. No hay un contador paralelo que pueda divergir de lo auditado.

Qué cuenta contra el cupo de llamadas de una conexión:

• Solo llamadas exitosas, de las categorías que ejecutan trabajo real: acciones, sincronizaciones y consultas del plano persistido. Un error factura 0.
• El peso por llamada lo declara cada conector; el peso por defecto es 1.
• Los conectores open (core, indicadores) y el plano de control (conexiones.*) facturan 0 siempre: la fila de bitácora existe igual, con billable_units en cero.
• Lo que haces desde el dashboard o desde el flujo hosted no consume cuota: guardar tu propia credencial o paginar tus propios datos no puede gastar el presupuesto de tu integración.

El cupo es de 2.000 llamadas por conexión al mes, y es el mismo número en los tres planes. Corta por conexión, no por organización: cada conexión mide su propio período contra su propio techo, y cuando una lo alcanza sólo ESA conexión responde 429 quota_exceeded. Las demás conexiones de la misma organización siguen operando sin cambios. Subir de plan no mueve este techo, porque no es un atributo del plan sino una constante del producto. Si tu organización tiene un cupo ampliado negociado, el vigente es el que aparece en /billing, junto al uso del período en curso.

Tres códigos distintos avisan que algo se frenó, y conviene no confundirlos:

El plan contratado sí gobierna otras dos cosas, y ninguna es el cupo de llamadas: cuántas conexiones incluye antes de que las siguientes se cobren como add-on, y si incluye webhooks (Starter no los incluye; Pro y Max sí). La sincronización programada no es una diferencia de plan: los tres la incluyen. Ninguno de los dos topes anteriores es una constante del código; el número vigente de tu organización está en /billing. El panel, en la portada del dashboard, muestra además un total de llamadas de la organización a modo informativo: no tiene techo propio y no corta nada, y el corte real sigue siendo el de la conexión, arriba. Crear un endpoint de webhook sin la función responde 403 feature_not_in_plan.

Próximos pasos

• El catálogo completo de códigos, con qué significa y qué hacer en cada uno: errores.
• Configurar los avisos de sincronización en lugar de sondear: webhooks.
• Qué es una conexión y por qué es la unidad de facturación: conexiones.
• La superficie de control que aplica estos topes: API de control.