Inspeccionar cabeceras HTTP
El cuerpo de una respuesta solo cuenta la mitad de la historia; las cabeceras le dicen qué servidor respondió, qué guardó en caché, qué cookies estableció y por dónde redirigió sin que lo notara. Esta API de cabeceras HTTP obtiene una URL y devuelve el conjunto completo de cabeceras como datos estructurados, para que las inspeccione desde código en vez de entrecerrar los ojos ante las herramientas de desarrollador del navegador.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
El problema de revisar cabeceras a mano
Las herramientas de desarrollador muestran las cabeceras de maravilla para una página a la vez, pero no escalan a una lista de cien URLs, y no pueden correr dentro de un pipeline de integración continua ni de una tarea nocturna. Cualquiera que haya copiado la salida de curl -I a una hoja de cálculo conoce el problema: funciona hasta que hay que repetirlo la semana siguiente, o para cada página de un sitio en vez de solo una.
Qué devuelve el endpoint
Llame a POST /web/headers con una URL y la tarea la obtiene y devuelve el conjunto completo de cabeceras de respuesta tal como las envió el servidor: tipo de contenido, identidad del servidor, directivas de caché, cookies, cabeceras propias de la aplicación, todo lo que va en la conexión. Como la respuesta viene estructurada, puede filtrar una sola cabecera por código en vez de analizar texto crudo.
Por qué las cabeceras dicen más de lo que parece
Las cabeceras HTTP existen desde las primeras versiones del protocolo como una forma de transmitir metadatos junto al contenido sin tocar el cuerpo, y esa separación es justamente lo que las hace tan útiles para la automatización: una cabecera revela un cambio estructural aunque la página visible se vea idéntica. Una cabecera de caché que revirtió sin que nadie lo notara, un identificador de servidor que filtró una pila que no quería exponer, o una bandera de cookie que se perdió en un despliegue son el tipo de regresiones que nunca se ven a simple vista en una página renderizada.
Cómo lo usan los equipos en la práctica
Como la tarea es asíncrona y se entrega por webhook firmado, encaja de forma natural en un pipeline de despliegue como verificación posterior al deploy, o en una tarea de monitoreo que toma una foto de las cabeceras según un horario y la compara con la de ayer. Eso convierte la inspección de cabeceras de un hábito manual y ocasional en un resguardo continuo y automático.
Qué buscar en realidad
Preste atención a cabeceras que deberían mantenerse estables entre despliegues —tipo de contenido, política de caché, identidad del servidor— y que cambian sin explicación, y a cabeceras que deberían existir pero simplemente no aparecen, porque una cabecera ausente suele ser tan reveladora como una con un valor incorrecto.
Qué puede hacer con ella
Verificaciones de regresión tras el despliegue
Compare las cabeceras antes y después de un release para detectar una directiva de caché o un tipo de contenido que cambió sin querer.
Depuración de CDN y proxies
Descubra qué capa respondió realmente una solicitud leyendo las cabeceras de servidor y estado de caché en vez de adivinar por el comportamiento.
Auditoría de cookies y sesiones
Confirme que las cookies de sesión llevan las banderas esperadas en todos los entornos, no solo en el que probó en un navegador.
Revisión de integraciones con terceros
Verifique que una API o un embed de un socio siga devolviendo el tipo de contenido y las cabeceras que su integración espera.
Preguntas frecuentes
¿Qué devuelve la API de cabeceras HTTP?
El conjunto completo de cabeceras de respuesta de la URL solicitada, tal como las envió el servidor, entregado como datos estructurados que puede procesar desde código.
¿Puedo revisar cabeceras de una URL que hace redirecciones?
Sí, la tarea sigue la cadena de respuestas y devuelve las cabeceras de la respuesta final alcanzada.
¿Es gratis usarla?
No hay capa gratuita: las capas gratis se abusan y ralentizan a todos. El acceso funciona con un saldo prepago de ForHosting KIT: se recarga desde $10.00 (no caduca) y cada solicitud se cobra a su precio publicado, así que una llamada sin saldo devuelve HTTP 402. Sin suscripción, sin tokens ni créditos inventados, y una tarea fallida no se cobra.
¿En qué se diferencia de curl -I?
Hace la misma consulta pero devuelve datos estructurados y analizables de forma asíncrona con resultado firmado, así que puede correr a escala dentro de pipelines en vez de una URL a la vez en una terminal.
¿Cómo recibo los resultados?
Mediante un webhook firmado cuando la tarea termina, que es lo recomendado para automatización, o un enlace firmado válido por 24 horas.
¿Se cobra si la solicitud falla?
No. Una tarea fallida se reintenta automáticamente hasta tres veces y nunca se cobra; solo se facturan las tareas completadas.
¿Cuál es el precio por solicitud?
$0.002 por solicitud, sin cargo adicional por cada cabecera devuelta.
¿Puedo revisar cabeceras en bloque para muchas URLs?
Sí, envíe cada URL como su propia tarea asíncrona y correlacione los resultados por task_id; el modelo asíncrono está pensado exactamente para ese volumen.
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/web/headers \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://ejemplo.com"}'const res = await fetch("https://api.kit.forhosting.com/web/headers", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://ejemplo.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/headers",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://ejemplo.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/headers", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://ejemplo.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://ejemplo.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/headers", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"url": "https://ejemplo.com"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.headers",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
timeout_sec | 30 |
max_crawl_pages | 25 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |