ForHosting KIT · Web Scraping & Monitoring

Inspect HTTP headers

The body of a response only tells half the story; the headers tell you what server answered, what it cached, what cookies it set and what it silently redirected through. This HTTP headers API fetches a URL and returns the complete raw header set as structured data, so you can inspect it in code instead of squinting at browser dev tools.

● StablePer request + per URL$0.002

Run — $0.002 How it works & API

Use it from WebAPIEmailApp soonTelegram soon

Run it online

Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.

The problem with checking headers by hand

Browser developer tools show headers beautifully for one page at a time, but they do not scale to a list of a hundred URLs, and they cannot run inside a CI pipeline or a nightly job. Anyone who has copy-pasted curl -I output into a spreadsheet knows the pain: it works until you need to do it again next week, or for every page on a site instead of just one.

What comes back from the endpoint

Call POST /web/headers with a URL and the task fetches it and returns the full response header set exactly as the server sent it — content type, server identity, caching directives, cookies, custom application headers, everything present on the wire. Because the response is structured, you can filter for a single header programmatically instead of parsing raw text.

Why headers carry more signal than most people think

HTTP headers have existed since the earliest version of the protocol as a way to pass metadata alongside content without touching the body, and that separation is exactly why they are so useful for automation: a header tells you what changed structurally even when the visible page looks identical. A caching header that quietly reverted, a server banner that leaked a stack you did not mean to expose, or a cookie flag that got dropped in a deploy are the kind of regressions that never show up by eyeballing a rendered page.

How teams put it to work

Because the task is asynchronous and delivered by signed webhook, it slots naturally into a deployment pipeline as a post-deploy check, or into a monitoring job that snapshots headers on a schedule and diffs today's set against yesterday's. That turns a header inspection from a manual, occasional habit into a continuous, automatic guardrail.

What to actually look for

Watch for headers that should be stable across deploys — content type, caching policy, server identity — changing unexpectedly, and for headers that should exist but are simply missing, since an absent header is often as telling as a wrong value. A quick diff between two snapshots, taken minutes or months apart, usually surfaces the change faster than reading any changelog.

What you can do with it

Deploy regression checks

Snapshot headers before and after a release to catch a caching directive or content type that silently changed.

CDN and proxy debugging

Inspect which layer actually answered a request by reading server and cache-status headers instead of guessing from behavior.

Cookie and session auditing

Confirm session cookies carry the flags you expect across every environment, not just the one you happened to test in a browser.

Third-party integration checks

Verify a partner API or embed still returns the content type and headers your integration was built to expect.

FAQ

What does the HTTP headers API return?

The complete set of response headers for the requested URL, exactly as the server sent them, returned as structured data you can parse in code.

Can I check headers for a URL that requires redirects?

Yes, the task follows the response chain and returns the headers of the final response reached.

Is this free to use?

There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.

How is this different from curl -I?

It does the same fetch but returns structured, parseable data asynchronously with a signed result, so it can run at scale inside pipelines instead of one URL at a time on a terminal.

How do I receive the results?

Through a signed webhook when the task finishes, which we recommend for automation, or a signed link valid for 24 hours.

Do I get charged for a failed request?

No. A failed task retries automatically up to three times and is never billed; only completed tasks are charged.

What is the price per request?

$0.002 per request, with no separate charge per header returned.

Can I check headers in bulk across many URLs?

Yes, submit each URL as its own async task and correlate results by task_id; the async model is built for exactly that kind of scale.

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/web/headers

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/web/headers \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d &#39;{"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[&#39;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" => &#39;{"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)

Example request

{
  "url": "https://ejemplo.com"
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "web.headers",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

Limits

`timeout_sec`	30
`max_crawl_pages`	25

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.

Read the full KIT documentation →