Scout · Concepts

Domain verify

Ownership verification unlocks sensitive browser ops (interact, evaluate, client cookies, Basic Auth, mTLS). Read-only checks against third-party URLs stay open without verify.

Why this exists
Without verify, anyone with a Scout key could drive arbitrary clicks or inject cookies on sites they do not own. Verify proves you control the hostname before Scout runs those actions. Cookie CMP dismiss (dismiss_cookie_banner) is the exception: only fixed vendor buttons, no custom selectors.

When it is required

Needs verified domainDoes not
Journey with interact / evaluate / client cookies; browse options http_auth / client_certificates screenshot, extract, inspect, performance, visibility, dns, robots, crawl, files, pdf, a11y/tech/security checks, read-only journeys, and dismiss_cookie_banner (fixed CMP allowlist — not free interact)

Console (My Account)

  1. Open Scout → Domains

    Sign in at account.macrocontent.dev → Scout → Domains. Domains are account-scoped: every sk_scout_… key on the account can use them.

  2. Add hostname

    Enter the host you own (e.g. www.example.com or example.com). Scout creates a pending domain and shows a challenge value.

  3. Publish the challenge

    • DNS TXT (preferred): create a TXT record at _scout-verify.<hostname> with the exact challenge value (form scout-verify=<token>). Apex TXT with the same value is also accepted.
    • Well-known file: serve https://<hostname>/.well-known/scout-verify.txt whose body is the same challenge value (plain text).
  4. Click Verify

    Scout checks DNS and/or the well-known file. On success the status becomes verified. Re-verify is required after ~90 days (configurable).

API flow

  1. Register the hostname

    POST/v1/domainsAPI key

    Creates (or returns) a pending domain + challenge. 0 credits.

    bash
    curl -X POST https://scout.macrocontent.dev/v1/domains \
      -H "Authorization: Bearer sk_scout_…" \
      -H "Content-Type: application/json" \
      -d '{"hostname":"example.com"}'

    Example response fields:

    json
    {
      "id": "dom_…",
      "hostname": "example.com",
      "status": "pending",
      "challenge": {
        "type": "dns_txt",
        "name": "_scout-verify.example.com",
        "value": "scout-verify=…",
        "token": "…"
      },
      "verified_at": null
    }
  2. List / inspect

    GET/v1/domainsAPI key

    List domains for this key’s account. 0 credits.

    GET/v1/domains/:idAPI key

    Fetch one domain by id (dom_…). 0 credits.

    bash
    curl https://scout.macrocontent.dev/v1/domains \
      -H "Authorization: Bearer sk_scout_…"
  3. Prove ownership, then verify

    Publish DNS TXT or the well-known file using challenge.name / challenge.value from the create response.

    POST/v1/domains/:id/verifyAPI key

    Checks DNS TXT and/or /.well-known/scout-verify.txt. 0 credits.

    bash
    curl -X POST https://scout.macrocontent.dev/v1/domains/dom_…/verify \
      -H "Authorization: Bearer sk_scout_…"
  4. Remove (optional)

    DELETE/v1/domains/:idAPI key

    Delete a domain registration. 0 credits.

Using a verified domain

For a sensitive journey, every navigate URL host must match a verified hostname (exact host or a verified parent, e.g. verified example.com covers www.example.com).

json
{
  "steps": [
    { "type": "navigate", "url": "https://example.com/login" },
    { "type": "interact", "action": "fill", "selector": "#email", "text": "demo.user" },
    { "type": "interact", "action": "click", "selector": "button[type=submit]" },
    { "type": "extract", "fields": [{ "name": "welcome", "selector": "h1", "type": "text" }] }
  ]
}
Common failure
403 DOMAIN_NOT_VERIFIED — register + verify the host first, or drop interact/evaluate/cookies so the journey stays read-only. Hint in the error body points to this flow.

Parameters (create)

NameTypeRequiredDescription
hostnamestringrequiredPublic hostname to verify (no scheme/path). Normalized (lowercase, no trailing dot).