Buenos días equipo Fracttal.

Escribo desde una planta siderúrgica cliente activa de Fracttal One. Tenemos una integración interna en producción que sincroniza los datos operativos con Fracttal cada 20-30 minutos.

Solicitud: evaluar la ampliación del límite de la API de 200 requests/minuto por IP a 500 requests/minuto por IP para nuestra cuenta, dado el volumen operativo real.

Contexto de volumen (datos actuales del tenant):

• 725 medidores activos con lecturas diarias

• 3,858 tareas de planes de mantenimiento distribuidas en 168 planes maestros

• 15,878 órdenes de trabajo históricas + ~50-80 nuevas por día

• 22,879 movimientos históricos de almacén + 1,500 a 3,000 movimientos nuevos por día

• 244 usuarios sincronizados con integración de biométrico

• 6 áreas operativas (Mecánico, Eléctrico, Automotriz, Soldadura, Refrigeración, Conformado) con visibilidad cross-área

Endpoints activos de nuestra integración:

• /api/work_orders/ — cada 20 min (sync OTs)

• /api/warehouses_items/ — cada 30 min (stocks)

• /api/warehouse_details_movements/ — actualmente desactivado en horas hábiles por el rate limit, corriendo solo nightly a las 03:00

• /api/purchase_orders/ — cada 2h (OCs)

• /api/employees/ — diario (padrón)

• /api/tasks/, /api/groups_tasks/, /api/work_orders/?type=PREVENTIVO — nocturno (planes de mtto)

• /api/meters/ — nocturno (catálogo medidores)

Impacto operacional del límite actual:

Desde el 13-14 de septiembre 2026, la aplicación estricta del límite de 200 req/min genera HTTP 429 sostenido en warehouse_details_movements — el endpoint más pesado (5,000+ movimientos por corrida × múltiples páginas). Consecuencias:

1. Deshabilitamos el sync intra-día de movimientos de almacén. Los ajustes de stock del turno matutino (06:00-14:00) recién se reflejan al día siguiente.

2. El planificador pierde visibilidad en tiempo real de consumos y salidas críticas.

3. La UX de la app se degrada — el indicador de frescura muestra "atrasado" en horario laboral.

Acciones que ya aplicamos de nuestro lado (documentadas con soporte, ticket del 16/9/2026):

• Bajamos frecuencia de 15 a 30 min.

• Bajamos concurrencia de 5 a 2 workers.

• Aumentamos throttle interno cliente a 1.5s entre páginas.

• Estamos implementando lectura de headers ratelimit-limit / ratelimit-remaining / ratelimit-reset para throttling dinámico.

• Bajaremos tamaño de página de 50 a 25 items.

Aún con todas estas mitigaciones, un volumen de 22,879 movimientos históricos + 1,500-3,000 nuevos por día contra un límite de 200 req/min hace matemáticamente imposible la sync intra-día. Con 500 req/min el problema desaparece.

Nuestra propuesta: ampliación a 500 req/min por IP para nuestro tenant. Estamos dispuestos a firmar cualquier acuerdo/adenda que requiera esta capacidad ampliada, o a evaluar un plan Enterprise si aplica.

Quedamos atentos a la evaluación del equipo. Muchas gracias.

Saludos.