# Límites > El tamaño máximo de petición, la emisión de enlaces, la cola de sincronizaciones y el cupo de llamadas por conexión. Cada número de esta página existe como constante en el código que lo aplica. 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](https://connect.emisso.ai/billing). ## Límites de petición [#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`](/docs/referencia/conexiones) 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 [#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](/docs/operar/webhooks). 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](/docs/conceptos/conexiones)). Hoy es `4h` en todos los conectores que sincronizan; si necesitas una frecuencia de actualización mayor, escríbenos a [contacto@tryemisso.com](mailto: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 [#medición-y-plan] La fuente de la medición es la [bitácora](/docs/conceptos/bitacora): 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](https://connect.emisso.ai/billing), junto al uso del período en curso. Tres códigos distintos avisan que algo se frenó, y conviene no confundirlos: | Código | Estado | Reintentable | Qué significa | Qué hacer | | ------------------ | ------ | ------------ | ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | `rate_limited` | 429 | Sí | Superaste un tope de tasa puntual (por ejemplo, la emisión de enlaces). | Espera y reintenta con backoff; respeta `Retry-After` cuando viene. | | `quota_exceeded` | 429 | No | Esta conexión alcanzó su cupo de llamadas del período. Tus demás conexiones siguen funcionando. | Espera el período siguiente o pide una ampliación. Subir de plan no cambia el cupo, y reintentar tampoco. | | `billing_past_due` | 402 | No | La organización tiene un pago vencido. | Regulariza el pago en [/billing](https://connect.emisso.ai/billing). Reintentar no paga la deuda. | `billing_past_due` pausa lo que trae datos nuevos del sistema externo (la sincronización, programada o a pedido) y la creación de conexiones. La lectura de lo ya persistido sigue abierta a propósito: esos datos son del cliente, ya están en Connect, y retenerlos como palanca de cobro sería retener información que le pertenece. 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](https://connect.emisso.ai/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 [#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](https://connect.emisso.ai/billing). 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. | Sistema | Módulos que se cargan | Ventana de solicitud | | -------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | SII | Compras y ventas, boletas electrónicas, boletas de honorarios | Según disponibilidad del SII, sin tope de antigüedad impuesto por Connect | | SII | Guías de despacho | Hasta 6 meses | | Previred | Planillas pagadas, cotizaciones por trabajador, archivo para el F30-1 | Según disponibilidad de Previred, sin tope de antigüedad impuesto por Connect | 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](https://www.sii.cl/preguntas_frecuentes/factura_electronica/001_003_6974.htm); esto no garantiza datos para cada empresa o período. Previred documenta un máximo de [36 meses por certificado de cotizaciones](https://www.previred.com/documents/80476/80730/C%C3%B3mo%2Bimprimir%2Bun%2Bcertificado%2Bde%2Bcotizaciones.pdf), 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 [#próximos-pasos] * El catálogo completo de códigos, con qué significa y qué hacer en cada uno: [errores](/docs/operar/errores). * Configurar los avisos de sincronización en lugar de sondear: [webhooks](/docs/operar/webhooks). * Qué es una conexión y por qué es la unidad de facturación: [conexiones](/docs/conceptos/conexiones). * La superficie de control que aplica estos topes: [API de control](/docs/api-control).