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.
• Techo global de operaciones externas: 4 simultáneas por defecto. El límite se comparte entre todas las instancias del servicio, no se multiplica con cada despliegue. Cuando todos los slots están tomados, una operación sobre cualquier conexión devuelve el mismo 409 connection_busy; los trabajos de la cola se difieren automáticamente y vuelven a intentarse sin gastar un intento. En un despliegue autogestionado, CONNECTOR_IN_FLIGHT_SLOTS permite fijar un entero entre 1 y 32; si no existe, se usan 4. Configura el mismo valor en todas las instancias y súbelo solo después de dimensionar el pool de Postgres.
• 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 del enum son off, daily, 12h, 6h y 4h, y ninguna se elige a mano: la decide Connect por conector y toda conexión activa la tiene (detalle). Hoy es 4h en todos los conectores que sincronizan; si necesitas una frecuencia de actualización mayor, escríbenos a contacto@tryemisso.com y te preparamos una propuesta. 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, con la misma frecuencia. 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.

Cargar histórico del SII y Previred

La prueba incluye el mes actual y los dos anteriores. Para cargar meses anteriores se requiere un plan activo; los precios vigentes están en Facturación. Guardar una tarjeta o autorizar un acuerdo sin pago aprobado no habilita esta capacidad. Una extensión gratuita conserva el límite de la prueba.

En Conexiones → tu conexión → Sincronización → Cargar histórico, el dueño o un administrador elige los meses y sigue la carga en un mapa. El panel ofrece meses desde el inicio de actividades de la empresa; la API no aplica ese piso. Se procesan primero los meses más recientes, con cargas escalonadas y sin cambiar la frecuencia automática. Cerrar la página no cancela los trabajos.

Cada carga acepta hasta 24 períodos. Es un límite del tamaño del lote, no de la antigüedad: puedes solicitar, por ejemplo, enero a diciembre de 2019 para SII o Previred, y después otro rango. El SII sitúa el inicio del RCV en agosto de 2017; esto no garantiza datos para cada empresa o período. Previred documenta un máximo de 36 meses por certificado de cotizaciones, que limita el rango de cada documento y no establece un máximo de antigüedad de las planillas.

Del 10 al 13 de cada mes, Previred solo acepta el mes actual y los dos anteriores (su período de pago); los meses más antiguos se pueden cargar desde el 14.

Las ventanas expresadas en meses incluyen el mes corriente. La disponibilidad depende del acceso de la conexión y de lo que conserve el portal: solicitar un período no garantiza que existan datos ni cobertura completa. Las nóminas actuales, la deuda actual, las empresas y la emisión de certificados nuevos de Previred no se repiten por cada mes. Esta carga no incluye bancos ni la recuperación de XML del SII. Las operaciones de XML y certificados que ya ofrece la API conservan su disponibilidad y permisos; quedar fuera de la selección del panel no las deshabilita para los clientes con acceso pagado.

La misma restricción de acceso se aplica al encolado REST y a las ejecuciones de sincronización por API o MCP; los períodos fuera de prueba devuelven feature_not_in_plan sin abrir sesión en el portal. Las consultas a datos ya guardados permanecen disponibles según los permisos de la conexión.

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.