# 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. * **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 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 [#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. 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`. ## 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).