Política de Disponibilidad

Última actualización: 2 de mayo de 2026
Versión: 2.0

Este documento describe cómo operamos Cotizave en términos de disponibilidad y respuesta a incidentes. Hoy no ofrecemos un SLA contractual con créditos automáticos: el servicio se opera en modo mejor esfuerzo con monitoreo activo. Un SLA contractual puede negociarse por acuerdo escrito a medida para volúmenes altos.

Este documento es parte de los Términos y Condiciones.

1. Modo de operación

Cotizave opera con monitoreo activo de los endpoints de la API. Cuando se detecta un incidente, el equipo es notificado automáticamente y trabajamos para restablecer el servicio lo antes posible. Comunicamos los incidentes relevantes por email y a través de la página de status.

No publicamos un porcentaje de uptime comprometido contractualmente en este momento. Cuando publiquemos un dashboard público de uptime histórico, migraremos a un SLA contractual para el plan Pro y este documento se actualizará con 30 días de aviso.

2. Qué se considera "disponible"

Para efectos de esta política, el servicio se considera disponible cuando:

• Los endpoints autenticados de la API responden con códigos HTTP 2xx o 3xx a requests válidos dentro de un timeout razonable (menor a 5 segundos)
• La autenticación con API Keys funciona correctamente
• Los datos devueltos corresponden al contrato documentado (schema válido, no errores de serialización)

3. Qué se considera "no disponible"

El servicio se considera no disponible cuando:

• Los endpoints cubiertos devuelven errores 5xx de forma sostenida (más de 1 minuto)
• Hay timeouts masivos (requests que no responden en menos de 10 segundos)
• La autenticación falla por problemas internos del servicio
• El contrato de respuesta se rompe (schemas inválidos, datos corruptos)

3.1 Dependencia de fuentes externas

Cotizave consume datos de fuentes oficiales (BCV) y de mercado (paralela, exchanges P2P). La disponibilidad de la API depende parcialmente de estas fuentes. Cuando una fuente está temporalmente no disponible, Cotizave puede devolver:

• El último dato válido conocido, marcado como stale: true en la respuesta.
• Un código 503 service_unavailable si no hay último dato válido disponible.

Esto no se considera incumplimiento del SLA. Los compromisos de uptime de Cotizave aplican a la disponibilidad de la API REST en sí, no a la frescura o disponibilidad de cada mercado individual cuando la fuente upstream experimenta degradación. Ver también la sección 5.2.

4. Endpoints cubiertos

Esta política cubre los siguientes endpoints:

El dashboard (app.cotizave.com) y el sitio web (cotizave.com, incluida la documentación en /docs) tienen cobertura best-effort y no están sujetos a compromisos formales de disponibilidad.

5. Exclusiones

Los siguientes eventos no cuentan como indisponibilidad a efectos de esta política:

5.1 Ventanas de mantenimiento planificado

Notificamos con al menos 48 horas de anticipación a través de email y de la página de status. El mantenimiento planificado se realiza preferentemente en horarios de bajo tráfico.

5.2 Factores externos fuera del control de Cotizave

• Fallas de la infraestructura de terceros (proveedores de hosting, CDN, DNS, etc.) más allá de lo razonablemente esperable
• Cortes masivos de Internet
• Ataques DDoS que superen las capacidades de mitigación razonables
• Desastres naturales, fuerza mayor, conflictos armados
• Fallas de las fuentes de datos upstream (BCV, Binance, etc.) — en estos casos la API sigue disponible pero puede devolver datos stale marcados como tal

5.3 Acciones del Usuario

• Uso del servicio fuera de los límites del plan contratado
• Errores en el código del cliente que generan requests inválidos
• Configuraciones incorrectas del lado del usuario
• Suspensión del servicio por incumplimiento de los Términos

5.4 Features beta o experimentales

Los endpoints marcados como "beta" o "experimental" en la documentación no están cubiertos por esta política hasta su promoción a "estable".

6. Medición de disponibilidad

Medimos disponibilidad mensual mediante monitoreo interno. Cuando publiquemos un dashboard público de uptime histórico, las métricas serán verificables contra la página de status.

7. Compromiso por plan

8. Transparencia

Publicamos el estado actual del servicio en la página de status. Cuando haya un incidente relevante, comunicamos el impacto y, una vez resuelto, publicamos un resumen explicando qué pasó, cuál fue la causa raíz y qué medidas tomamos.

9. Cambios a esta política

Podemos modificar esta política con al menos 30 días de anticipación para los usuarios activos en planes pagos. Los cambios que mejoren los compromisos pueden aplicarse inmediatamente sin aviso previo.

Si un cambio reduce sustancialmente tus derechos, puedes cancelar tu plan sin penalización dentro de los 30 días posteriores a la notificación. Los pagos ya realizados no son reembolsables (ver Términos y Condiciones), pero mantendrás el acceso al servicio hasta el vencimiento del ciclo pagado.

10. Contacto

• Para consultas sobre disponibilidad: support@cotizave.com
• Página de status: status.cotizave.com

11. Tiempos de respuesta de soporte

Este apartado describe el tiempo de primera respuesta del equipo de soporte por email (distinto de la disponibilidad de la API cubierta en las secciones 1 a 10).

Días hábiles = lunes a viernes en zona horaria de Argentina (UTC-3, donde reside operativamente el equipo de soporte), excluyendo feriados nacionales argentinos. Fines de semana respondemos en modalidad best-effort cuando el equipo está disponible, sin compromiso formal — si tu caso es urgente, igualmente escribinos. El incumplimiento de los tiempos comprometidos no genera créditos automáticos, pero puede escalarse a support@cotizave.com para revisión caso por caso.

Nota: este documento se actualizará cuando publiquemos un dashboard público de uptime histórico, lo que habilitará un SLA contractual con créditos automáticos para el plan Pro. Hasta entonces operamos en modo mejor esfuerzo con comunicación transparente de incidentes.