Synthetic multi-step

El monitor synthetic multi-step verifica flujos completos de varias llamadas HTTP en secuencia: login, obtención de token, llamada autenticada, verificación del resultado. En lugar de comprobar un solo endpoint, simula lo que haría un usuario o sistema real interactuando con tu API paso a paso.

Es un modo avanzado que se activa desde el editor del monitor HTTP/API. Está disponible en los planes Pro y Enterprise.

¿Cuándo usarlo?

Un check HTTP básico no es suficiente cuando tu servicio requiere más de una petición para funcionar. Usa synthetic multi-step cuando necesites:

Verificar flujos con autenticación (login → token → endpoint protegido).
Comprobar que puedes crear un recurso y luego consultarlo correctamente.
Validar secuencias críticas de negocio como un proceso de checkout o un flujo de pagos.
Asegurarte de que varios endpoints encadenados funcionan como un todo.

Cómo funciona

Defines un escenario de hasta 10 pasos. Cada paso hace una petición HTTP y puede:

Validar la respuesta con assertions (código HTTP, contenido, valores JSON).
Extraer variables del resultado para usarlas en los pasos siguientes.

Si cualquier paso falla, el escenario se detiene y el monitor pasa a DOWN. El estado final refleja el resultado del conjunto, no de un paso individual.

Definición de un paso

Cada paso se define con estos campos en el JSON del escenario:

Campo	Descripción
`name`	Nombre del paso — aparece en la traza para facilitar el diagnóstico.
`method`	Método HTTP: `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `HEAD`.
`url`	URL del endpoint. Puede incluir variables entre llaves: `{{nombre}}`.
`timeout_ms`	Tiempo máximo de espera para este paso, en milisegundos (máximo 30 000).
`headers_json`	Cabeceras de la petición como objeto JSON.
`body_template`	Cuerpo de la petición. Puede incluir variables entre llaves: `{{nombre}}`.
`extractors`	Variables a extraer de la respuesta para usar en pasos siguientes.
`assertions`	Validaciones sobre la respuesta de este paso.
`continue_on_failure`	Si `true`, el escenario continúa aunque este paso falle.

Variables entre pasos

Los extractores capturan un valor de la respuesta de un paso y lo hacen disponible en los siguientes usando la sintaxis {{nombre_variable}}.

Extractor desde el cuerpo JSON:

{ "name": "auth_token", "path": "data.token" }

Uso en el paso siguiente:

Authorization: Bearer {{auth_token}}

Extractor desde una cabecera de respuesta:

{ "name": "request_id", "source": "header", "header": "x-request-id" }

Notación de rutas: usa puntos para navegar en objetos anidados o arrays. El primer elemento de un array es el índice 0:

Ruta	Accede a
`data.token`	Campo `token` dentro de `data`
`items.0.id`	Campo `id` del primer elemento de `items`

Variable no encontrada: si la variable que usa un paso no existe, el check falla con el código synthetic_variable_missing. Puedes definir un valor por defecto como fallback: {{auth_token:valor-por-defecto}}.

Assertions por paso

Cada paso puede tener una o más validaciones sobre su respuesta. Si alguna falla y el paso no tiene continue_on_failure, el escenario se detiene:

Tipo	Descripción
`http_code`	El código HTTP es exactamente el indicado (ej. `200`).
`http_code_in`	El código HTTP está en la lista indicada (ej. `[200, 201]`).
`body_contains`	El cuerpo de la respuesta contiene el texto indicado.
`json_exists`	El path JSON existe en la respuesta.
`json_equals`	El valor en el path JSON es igual al esperado.
`json_gt` / `json_gte`	El valor numérico en el path es mayor (o mayor o igual) que el esperado.
`json_lt` / `json_lte`	El valor numérico en el path es menor (o menor o igual) que el esperado.
`json_regex`	El valor en el path cumple el patrón de expresión regular indicado (máx. 256 caracteres).
`header_equals`	La cabecera de respuesta tiene exactamente el valor indicado.
`header_contains`	La cabecera de respuesta contiene el texto indicado.
`latency_lt`	La latencia de este paso es menor que N milisegundos.
`latency_gt`	La latencia de este paso es mayor que N milisegundos.

[
  {
    "name": "Login",
    "method": "POST",
    "url": "https://api.ejemplo.com/auth/login",
    "timeout_ms": 5000,
    "headers_json": { "Content-Type": "application/json" },
    "body_template": "{\"email\":\"monitor@ejemplo.com\",\"password\":\"secreto\"}",
    "extractors": [
      { "name": "token", "path": "data.access_token" }
    ],
    "assertions": [
      { "type": "http_code", "value": 200 },
      { "type": "json_exists", "path": "data.access_token" }
    ]
  },
  {
    "name": "Endpoint protegido",
    "method": "GET",
    "url": "https://api.ejemplo.com/v1/profile",
    "timeout_ms": 5000,
    "headers_json": { "Authorization": "Bearer {{token}}" },
    "assertions": [
      { "type": "http_code", "value": 200 },
      { "type": "json_exists", "path": "data.id" }
    ]
  }
]

Opciones del escenario

Además de los pasos, puedes configurar opciones globales del escenario desde el editor:

Opción	Descripción
Tiempo máximo del escenario	Límite de tiempo total para ejecutar todos los pasos. Si se supera, el check falla con `synthetic_scenario_timeout`.
Latencia acumulada máxima	Si la suma de latencias de todos los pasos supera este valor pero no hay errores, el resultado es DEGRADED en lugar de DOWN.
Detalle del cuerpo en la traza	Controla si los cuerpos de respuesta se guardan en la traza: sin cuerpo (por defecto), truncado, o completo. Ver nota de seguridad más abajo.

Estado del escenario

El check produce un único resultado global:

Estado	Cuándo ocurre
UP	Todos los pasos completados sin errores.
DOWN	Al menos un paso falló (y no tenía `continue_on_failure` activo).
DEGRADED	Todos los pasos OK, pero la latencia acumulada supera el umbral configurado.

Traza de ejecución

Cada check guarda una traza detallada por pasos, visible desde el historial del monitor. Para cada paso puedes ver:

Nombre del paso y URL ejecutada (ya con las variables interpoladas).
Estado del paso, código HTTP y latencia.
Qué assertion falló, si aplica.
El cuerpo de la respuesta, si tienes activado el detalle de cuerpo en la traza.

La URL ejecutada es especialmente útil cuando usas variables en la URL: puedes ver exactamente qué valor se resolvió en cada ejecución.

Códigos de error

Cuando el escenario falla, el código de error indica dónde y por qué:

Código	Qué ocurrió	Qué revisar
`synthetic_variable_missing`	Un paso usa `{{variable}}` que no existe en el contexto.	Que el extractor del paso anterior define exactamente ese nombre; revisar ortografía y mayúsculas.
`synthetic_http_failed`	Fallo de red o transporte en un paso.	DNS, TLS, firewall y conectividad hacia el endpoint.
`synthetic_bad_response`	La respuesta no es JSON válido cuando el paso necesita JSON.	Que el endpoint devuelve JSON y que los headers de la petición son correctos.
`synthetic_extractor_failed`	El path del extractor no existe en la respuesta.	El cuerpo real de la respuesta y el path configurado en el extractor.
`synthetic_assertion_failed`	Una assertion del paso no se cumplió.	La traza para ver qué assertion falló y qué valor devolvió el endpoint.
`synthetic_scenario_timeout`	El tiempo total del escenario superó el límite configurado.	Aumentar el límite o revisar si algún endpoint está respondiendo lento.
`synthetic_scenario_partial_failure`	Al menos un paso falló con `continue_on_failure` activo.	La traza de cada paso en DOWN.

Seguridad y datos sensibles

Los valores de las variables extraídas entre pasos no se guardan en la traza.
Si activas el detalle del cuerpo en la traza, los cuerpos de respuesta se guardan aplicando un filtro automático que elimina patrones típicos de secretos (tokens, contraseñas, claves de API).
Las credenciales configuradas en las cabeceras de los pasos se enmascaran antes de almacenarse.

Plantillas de escenario

Desde el editor puedes cargar plantillas predefinidas con un clic para los flujos más comunes:

Login + Bearer — autenticación con token y llamada protegida.
Lista → detalle (JSON:API) — obtiene una lista y consulta el primer elemento por id.
Lista → detalle (API key) — misma variante con autenticación por API key.

También puedes guardar tus propios escenarios como plantillas reutilizables desde Configuración → Plantillas synthetic (hasta 25 plantillas en Pro, ilimitadas en Enterprise).

Limitaciones actuales

Limitación	Detalle
Máximo de pasos por escenario	10
Timeout máximo por paso	30 segundos
Extractor desde respuesta no-JSON	No soportado; solo cuerpo JSON o cabeceras de respuesta
Editor visual de pasos	El escenario se edita en JSON; las plantillas cubren los casos más comunes

¿Cuándo usarlo?​

Cómo funciona​

Definición de un paso​

Variables entre pasos​

Assertions por paso​

Ejemplo completo: login y endpoint protegido​

Opciones del escenario​

Estado del escenario​

Traza de ejecución​

Códigos de error​

Seguridad y datos sensibles​

Plantillas de escenario​

Limitaciones actuales​