Audit cookies
A consent banner is only honest if it matches what the page actually does, and most sites have no idea what that is until someone checks. This endpoint loads a URL, records every cookie it sets and every tracker it fires, and hands back a categorized inventory — the same document a privacy audit or a regulator would ask you to produce.
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 gap between the consent banner and reality
A cookie banner gets written once, usually early in a site's life, and the site keeps evolving after that: a new analytics snippet gets added by a marketing tool, an embedded video pulls in a third-party tracker nobody flagged, an A/B testing tool sets a cookie that was never disclosed. None of it is usually malicious — it's drift, the same way any list goes stale if nobody re-checks it against what's actually running. web.cookie_audit exists to catch that drift by actually loading the page and observing what it does, rather than trusting a document written months or years ago.
What the audit captures
POST /web/cookie-audit with a URL, get a task_id back immediately, and receive a structured inventory by signed webhook or a signed link once the async job finishes. The report lists each cookie set, its name, domain, expiry and the category it falls into — strictly necessary, functional, analytics or marketing — along with the third-party trackers and scripts the page loads, so the gap between what a privacy policy claims and what the page actually does becomes visible line by line.
Why categorization matters, not just detection
Data-protection frameworks that require consent before non-essential cookies are set — the kind widely adopted since the mid-2010s — don't just require knowing that a cookie exists, they require knowing what it's for, since strictly necessary cookies are typically exempt from consent while analytics and marketing cookies are not. A flat list of cookie names without that classification tells you very little; the categorization is what turns a technical scan into something a compliance review can actually use.
Fitting into a compliance routine
Legal and privacy teams run this before publishing an updated cookie policy, after a marketing team adds a new tag or pixel, and periodically as a standing check that the banner still matches reality, since new tools get added to sites far more often than privacy policies get rewritten. Priced per request plus per URL, auditing a full site map of pages costs in direct proportion to how many pages you check, which makes routine re-auditing practical rather than something reserved for a once-a-year scramble before a policy deadline.
What you can do with it
Pre-publish policy verification
A privacy team audits a site before publishing an updated cookie policy to confirm the disclosed categories match what the page actually sets.
Post-integration tracker check
A team audits a page right after adding a new marketing pixel or analytics snippet to catch any undisclosed tracker before it goes live to the public.
Recurring compliance monitoring
A legal team schedules periodic audits across key pages so drift between the banner and reality gets caught before an external review does.
Agency due diligence for clients
An agency audits a client's site during onboarding to document existing cookie and tracker exposure before proposing any changes.
FAQ
How do I scan a website's cookies with the API?
POST the page URL to /web/cookie-audit, keep the returned task_id, and collect the categorized cookie and tracker inventory by webhook or a signed link valid for 24 hours.
Is the cookie audit API free?
No, there is no free tier or trial; it costs $0.040 per request plus $0.001 per URL, and a failed task is never charged.
Does the audit categorize cookies automatically?
Yes, each cookie found is reported with its name, domain and expiry along with the category it falls into, such as necessary, functional, analytics or marketing.
Does this replace a legal compliance review?
No, it produces the factual inventory of what a page actually sets and loads; how that maps to a specific legal obligation is a compliance judgment for your team or counsel to make.
Can I audit multiple pages of a site?
Yes, each request covers the URL you submit, and you can queue a request per page for full-site coverage; it's priced per request plus per URL.
Does it detect third-party trackers too, or just cookies?
Both — the report includes third-party scripts and tracking pixels the page loads, not only the cookies it sets.
Is this endpoint live yet?
Yes, it's live and accepting requests now.
Is the scanned page data kept afterward?
No, page content and results are deleted after the retention window and are never used for training.
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
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/cookie-audit \
-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/cookie-audit", {
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/cookie-audit",
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/cookie-audit", 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/cookie-audit", 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.cookie_audit",
"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
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. |
422 | task_failed | The task failed after 3 retries. You are never charged for it. |