Scan for AI visibility from code, or from Claude.

Reference

REST API

Get an API key

Access uses a key (a Bearer token that looks like lantad_…) with a daily scan cap, because every scan runs a real browser render. Any paid plan that includes the API issues your key automatically: it is on your account dashboard the moment you subscribe (Starter from $59/mo, Pro from $199/mo, Business from $399/mo). Send the key as an Authorization: Bearer header; never put it in a URL or commit it to a repo. Need higher limits or a custom arrangement? Email hi@lantad.co.

Start a scan

curl -X POST https://lantad.co/api/v1/scan \
  -H "Authorization: Bearer lantad_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "yoursite.com"}'

A bare domain works; no scheme needed. Returns 202 with a scan_id, a report_key, and the URLs to poll and to fetch the result:

{
  "scan_id": "1c2fecfa-…",
  "report_key": "noYTkhb0v3cTrpBPo7hpK",
  "status": "queued",
  "report_url": "https://lantad.co/r/noYTkhb0v3cTrpBPo7hpK",
  "status_url": "https://lantad.co/api/v1/scan/1c2fecfa-…",
  "result_url": "https://lantad.co/api/v1/report/noYTkhb0v3cTrpBPo7hpK"
}

Check status

curl https://lantad.co/api/v1/scan/SCAN_ID

Returns { "status": "queued" | "running" | "done" | … } plus the sub-scores once the grade lands. Scans usually finish in under a minute.

Get the full report

curl https://lantad.co/api/v1/report/REPORT_KEY

Returns the complete structured verdict: the AI Visibility Score and grade, Prose Parity and the other sub-scores, the per-bot access matrix for all checked crawlers, the ranked defects with their fixes, and the evidence behind each. The report_key is the capability, so this endpoint needs no key, exactly like the shareable web report.

A complete poll loop

There is no completion webhook: start the scan, poll the status_url it returns until the status leaves the queue, then fetch the result_url. In shell, with jq:

# 1. Start the scan and keep the URLs it returns
resp=$(curl -s -X POST https://lantad.co/api/v1/scan \
  -H "Authorization: Bearer lantad_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "yoursite.com"}')
status_url=$(echo "$resp" | jq -r .status_url)
result_url=$(echo "$resp" | jq -r .result_url)

# 2. Poll every few seconds until the scan settles
while :; do
  status=$(curl -s "$status_url" | jq -r .status)
  if [ "$status" != "queued" ] && [ "$status" != "running" ]; then break; fi
  sleep 3
done

# 3. Fetch the structured verdict
curl -s "$result_url" | jq .verdict.scores

queued and running are in flight; everything else is terminal. done usually carries a graded report, but it can also carry an honest ungraded verdict with a null composite when the page could not be measured fairly (a bot challenge, a login wall, or too little readable text); read the verdict state, not just the status. The other honest endings: render_blocked (the render was refused or timed out, so you get a partial verdict without a grade), deferred_budget (our daily render budget or the monthly spend ceiling had no room, so the browser view was deferred and re-queued), not_html, opted_out, and failed. When a scan ends without producing a report, the result endpoint returns ready: false with a message saying so; it never invents numbers for a scan that was not measured.

Errors, precisely

Every error response is JSON with an error field describing what to change. The status codes the v1 routes actually return:

Limits and behaviour

• A repeat scan of the same URL inside 24 hours returns the existing report and does not use budget.
• Each key has a daily scan cap, resetting at 00:00 UTC: 200 scans a day on Starter, 500 on Pro, 1,000 on Business. The counter is a soft limit: it lives in an eventually consistent store, so a burst right at the boundary may land a request or two either side of the cap.
• The cap follows your live plan, not the key: upgrade and the higher cap applies on the next request, no re-minting. The same re-check cuts a key off the moment its plan stops being active.
• Keys from one-time purchases expire with the bundled monitoring months (3 for Deep Audit, 6 for Fix Sprint); subscription keys carry no expiry of their own because the entitlement re-check governs them.
• The same SSRF and safety guards as the web form apply: private, reserved, and non-HTTP targets are refused.

Bulk sitemap audit (paid plans)

curl -X POST https://lantad.co/api/v1/bulk \
  -H "Authorization: Bearer lantad_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sitemap": "https://yoursite.com/sitemap.xml"}'

Audits every same-site page in the sitemap with the raw-HTML checks (no browser render): readability verdict, structure facts, structured data, and per-crawler robots access. Poll GET /api/v1/bulk/ID for progress; results include a shareable page and a per-page CSV. Included with Starter (up to 2,000 pages per job, 30,000 per month), Pro (up to 4,000 pages per job, 100,000 per month) and Business (up to 6,000 pages per job, 200,000 per month). The one-time Deep Audit covers 10,000 pages, granted once rather than monthly.

Deploy hook (paid plans)

Monitoring re-checks your pages weekly, which leaves a week-wide hole: a deploy that puts your content back behind JavaScript is invisible until the next run. Call this when a deploy lands and we re-check the pages you monitor straight away.

curl -X POST https://lantad.co/api/v1/deploy \
  -H "Authorization: Bearer lantad_YOUR_KEY"

No body. The key identifies the account, and we re-check the pages already monitored on it, least-recently-checked first. Results arrive the usual way: each page gets a report, and your existing alerts fire if something broke.

{
  "queued": 12,
  "skipped": 1,
  "budget_stopped": false,
  "remaining_today": 188
}

skipped counts pages we could not scan right now, usually a domain that has since opted out. budget_stopped is true when the platform's spend ceiling was reached partway through, so you can tell a short run from a complete one instead of guessing from the count.

Limits. One call per account per 10 minutes, and up to 200 pages re-checked per account per day across every call. A call inside the cooldown answers 429 with retry_after_seconds; one past the day's allowance answers 429 and queues nothing. Deploying more often than the cooldown is fine, the extra calls are simply refused, so you can wire it to every deploy without branching on the result.

What it is not. This re-checks pages you already monitor; it does not add pages, and a page that is not monitored is not scanned. It is available on every paid plan with the API (Starter, Pro and Business), using the same key as the rest of this API, so revoking the key revokes the hook.

Brand metrics (paid plans)

Your prompt-tracking history as data: one row per UTC day on which at least one of your verified prompt runs finished, covering the last 365 days. The same rows the dashboard's brand-visibility trends draw, so a chart you saw and a number you fetched can never disagree.

curl https://lantad.co/api/v1/brand-metrics \
  -H "Authorization: Bearer lantad_YOUR_KEY"

Read the nulls honestly. A null metric means it was not measured that day, never zero: a day with no graded answers has sentiment_net: null, a day where no engine returned attributable sources has citation_share: null, and a day where no answer named the brand has avg_position: null (positions are 1-based, lower is better; 0 is not a possible value). A real 0 is a measured claim and is returned as 0. A realistic response, nulls included:

{
  "window_days": 365,
  "note": "One row per UTC day with at least one finished verified prompt run. A null metric means it was not measured that day, never zero.",
  "rows": [
    {
      "day": "2026-08-03",
      "mention_rate": 40,
      "sentiment_net": 0.25,
      "citation_share": 12,
      "avg_position": 2.3,
      "runs": 2,
      "sov": [{ "name": "Rival Co", "count": 3, "isPinned": true }]
    },
    {
      "day": "2026-08-06",
      "mention_rate": 35,
      "sentiment_net": null,
      "citation_share": null,
      "avg_position": null,
      "runs": 1,
      "sov": []
    }
  ]
}

Requires a plan-issued key: the key identifies the account whose history is returned, so a key not minted by a plan answers 403. The same rows are downloadable from the dashboard as CSV or JSON without touching the API.