Cómo configurar la monitorización de API en HostTracker

2026-09-05 Actualizado: 2026-09-14

Una comprobación API pide un endpoint igual que lo hace una comprobación HTTP, y luego va un paso más allá: interpreta el cuerpo de la respuesta como JSON, XML o texto plano y valida un valor concreto dentro de él, en lugar de solo el código de estado. Úsala para un endpoint REST o SOAP cuyos datos quieras verificar, por ejemplo un campo de estado, un recuento de stock o un precio. Si solo necesitas confirmar que una URL carga y devuelve un estado aceptable, una comprobación HTTP es la opción más simple.

Configuración principal

No hay captura de pantalla de esta sección para el tipo API, pero usa los mismos controles compartidos que cualquier otro tipo de comprobación. Monitoring enabled es el interruptor maestro de encendido/apagado. Interval schedule (de 1 minuto a 24 horas, deslizador o desplegable) o un constructor de Cron schedule (cada N minutos/horas, diario, semanal, mensual, o una expresión personalizada, solo en plan de pago) controla con qué frecuencia se ejecuta la comprobación. Timeout va de 1 a 100 segundos; el tiempo de resolución DNS no cuenta. Tags son etiquetas separadas por comas para agrupar y filtrar. Full Log guarda cada resultado en lugar de agrupar los idénticos consecutivos, y Open Stats publica las estadísticas y el registro de la tarea en un enlace público. A diferencia de HTTP, el formulario de API no tiene el interruptor DNSBL (DNSBL solo persiste para Http/Ping/Port); sí lleva las mismas tarjetas de Domain Expiration, Certificate Expiration y Web Risk, cada una ejecutándose cada 12 horas: los recordatorios de caducidad siguen tus suscripciones Up de abajo, un mal resultado sigue Down/Repeat.

Configuración de la petición

HTTP Method: GET, HEAD, POST, PUT, DELETE o PATCH. GET (por defecto) es necesario para leer y analizar un cuerpo de respuesta; HEAD solo obtiene cabeceras.
Request body (solo POST/PUT/PATCH): Raw body envía exactamente lo que escribes (añade tu propia cabecera Content-Type para describir json/xml/texto plano); POST parameters acepta un KEY=VALUE por línea y se envía como cuerpo form-urlencoded.
Redirect behavior: Immediate response juzga la primera respuesta tal cual; Follow redirects (por defecto) sigue la cadena, con un deslizador de Max redirects to follow (1-20); Redirect is error hace fallar ante cualquier redirección (no disponible en modo de aserciones).
HTTP Headers: pares nombre/valor personalizados, con sugerencias de lista para nombres y valores de cabecera de API habituales (Content-Type, Authorization, X-API-Key, prefijos Bearer/Basic y más). Si se deja vacío, la sonda envía las cabeceras por defecto (User-Agent, Accept, Accept-Language, un Referer).
Request authentication: revela usuario/contraseña para la propia autenticación por desafío HTTP del servidor (Basic, Digest, NTLM, Kerberos, Negotiate). Para un token bearer o una clave de API, añade en su lugar una cabecera Authorization arriba.
DNS Server Selection: Default DNS servers at locations; Public DNS servers of location's country; o Manually defined DNS servers (tus propias IP de resolutor). Las dos últimas necesitan un plan de pago.
Disable DNS cache: fuerza una consulta DNS nueva en cada comprobación en lugar de reutilizar la caché del agente.

Validación de respuesta

Por defecto una comprobación tiene éxito cuando el DNS resuelve, se completan la conexión y el saludo TLS (para https), el servidor devuelve un estado HTTP Ok, y la respuesta se interpreta según el formato seleccionado abajo.

Assertion mode: la captura lo muestra desactivado, con un banner que invita a activarlo para reglas de código de estado, tiempo de respuesta, cabecera o contenido del cuerpo. API y HTTP son los dos únicos tipos de comprobación con un editor de aserciones funcional; consulta la referencia completa del modo de aserciones para el lenguaje de reglas completo. Mientras está desactivado, los campos clásicos de abajo deciden el veredicto.
Ignore HTTP Errors: códigos de estado que NO deberían hacer fallar la comprobación, por ejemplo 401, 403, 500; vacío significa que cualquier código 400+ es un error.
Error on these HTTP statuses: lo contrario: códigos que deberían hacer fallar la comprobación aunque normalmente no lo harían.
Response format: cómo se interpreta el cuerpo antes de que se ejecute el selector: JSON analysis (JSONPath o selector de propiedad, el que se ve seleccionado en la captura), XML analysis (consulta XPath), o String analysis (regex con captura). GET es necesario para leer un cuerpo.
Selector: extrae un valor de la respuesta interpretada; déjalo vacío para usar toda la respuesta como valor.
What to check: por defecto la condición de abajo juzga el propio valor seleccionado (Check the obtained value itself); cambia a Check the value change between checks, o a una tasa de cambio por segundo/minuto, para juzgar en su lugar cuánto se movió el valor.
Condition: compara el valor: any (no validation) (por defecto, el que se ve en la captura), equal to, not equal to, in set of, out of set, less than, less or equal, greater than, greater or equal, in range, out of range, absent in content, o json null. Todas las condiciones salvo las dos últimas necesitan un valor de comparación introducido debajo.
HTTP Policies: las mismas comprobaciones opcionales de cabecera/cookie/contenido que el tipo de comprobación HTTP: Enforce HTTPS, cabecera HSTS, sin degradación de https a http, CSP, protección contra clickjacking, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, sin revelar versión, aserciones de Cache-Control, cabeceras de respuesta CORS, seguridad de cookies y contenido mixto. Los presets Baseline, Strict y API sustituyen toda la selección; una infracción concluye la comprobación como Down igual que cualquier otro fallo.
TLS Handshake: cuatro interruptores de estrictura (plan de pago): exigir una cadena de certificado SSL válida, exigir TLS 1.2 o superior, bloquear cifrados débiles (128 bits o menos), y comprobar la revocación del certificado.
Expected IPs validation: confirma que el DNS resuelve tu host a una de las IP que listas en cada comprobación, detectando un secuestro o un registro obsoleto incluso mientras algún servidor sigue respondiendo.
Max response size: deja de leer el cuerpo pasado este tamaño, así que el analizador y el selector solo ven la parte descargada. Por defecto 1 MB, máximo 10 MB; 0 no lee ningún cuerpo.

Una nota sobre las capturas de arriba: se tomaron en una cuenta cuyo plan no incluye el tipo de comprobación API, así que el campo de selección de tipo ahí decía "not in your package". Eso es un artefacto de la cuenta de prueba, no algo que vayas a ver tú; por lo demás, cada campo y valor por defecto descrito aquí es exactamente lo que muestra el formulario.

Suscripciones de alerta

Compartido por cada tipo de comprobación. Down = el endpoint falló la comprobación, Up = se recuperó, Repeat = recordatorios mientras sigue caído. Subscribe all contacts to Up/Down events es un atajo; la tabla da control por contacto, de forma individual o mediante grupos de contactos reutilizables. Una tarea sin suscripciones de alerta se sigue ejecutando y registrando resultados; simplemente nunca avisa a nadie.

Suscripciones de informes

Informes periódicos de uptime, solo por correo. Elige Daily, Weekly o Monthly por contacto; Monthly también incluye resúmenes trimestrales y anuales. El interruptor de suscribir a todos funciona igual que en Suscripciones de alerta.

Ubicaciones de monitorización

Selector de ubicaciones: busca o navega por el árbol de regiones/países y marca las ubicaciones desde las que comprobar; cada fila muestra los agentes disponibles frente a los seleccionados. "Copy locations from another task" reutiliza un conjunto existente.
Estrategia de reintento: ante una transición de estado (por ejemplo, de Up a Down), varias ubicaciones la vuelven a verificar antes de aceptar el estado nuevo, protegiendo contra un falso positivo de una región. Opciones: voto por mayoría por defecto; un número especificado de ubicaciones que confirmen Down (añade un deslizador de 1 a 7); sin reintento; acuerdo total de todas las ubicaciones de reintento; o acuerdo total para Down, voto por mayoría para Up.
Si las ubicaciones seleccionadas no están disponibles: Selected locations only (por defecto) espera en lugar de arriesgarse a una falsa alerta; Closest locations usa la ubicación disponible más cercana; Any location recurre a cualquier sitio del mundo.

Ejemplo resuelto

Monitorizar un endpoint de estado en JSON: comprobación API, intervalo de 5 minutos, timeout de 40s, GET, Follow redirects (máx. 20). Response format JSON analysis, Selector $.status, What to check "the obtained value itself", Condition "equal to" con valor de comparación ok. Ignore HTTP Errors se deja vacío. Ubicaciones de monitorización se deja en Todo el mundo con la estrategia de reintento por defecto. El correo del equipo de guardia suscrito a Down, Up y Repeat, y a informes semanales.

Solución de problemas

La comprobación siempre pasa aunque el endpoint esté claramente roto: Condition tiene por defecto any (no validation), que solo juzga el análisis y el transporte, no el valor en sí. Elige una condición y un valor de comparación reales en cuanto sepas cómo es una respuesta sana.
El selector no devuelve nada: confirma que Response format coincide con lo que devuelve el endpoint (JSON frente a XML frente a texto plano); un selector JSONPath contra un cuerpo XML nunca coincide. Deja primero Selector vacío para confirmar que llega toda la respuesta, y luego acótalo.
Una Condition numérica (greater than, in range, etc.) da error: necesita que el valor seleccionado se convierta en número. Un selector que apunta a una cadena, o un cálculo en modo de cambio sin comprobación anterior todavía, no le da nada con qué comparar.
Pasó a Down justo después de activar HTTP Policies (sobre todo Strict): Strict espera cabeceras que muchas APIs no han configurado. Arregla las cabeceras, baja a Baseline, o ejecuta las políticas primero como una tarea aparte.
El selector deja de encontrar un valor en una respuesta grande: Max response size corta el cuerpo, así que nada más allá del corte llega al analizador ni al selector. Súbelo.

Relacionado

Monitorización y validación de API: la página de producto de este tipo de comprobación.
Comprobación instantánea gratuita HTTP/API: ejecuta una comprobación puntual sin necesidad de cuenta.
Reglas de validación de respuesta en modo de aserciones: el lenguaje de reglas completo detrás de Validación de respuesta.
API de HostTracker: automatiza la gestión de monitores desde tu propio código.
Documentación de la API v2: la referencia completa de la API usada para construir integraciones.
429 Too Many Requests: el estado que devuelve una API cuando el que llama tiene un límite de tasa, y qué hacer al respecto.
Todas las guías de monitorización: la guía de configuración de cada otro tipo de comprobación.