Macro Scout

Why Scout

Teams that need repeatable evidence about how a page looks and behaves in a browser — without building and operating their own headless fleet. Typical uses:

• QA & release checks — screenshots, visibility, a11y/tech facts in CI
• Ad & attribution verification — is the badge/link present and not covered?
• Content & SEO ops — extract fields, inspect meta/JSON-LD, crawl link graphs
• Multi-step flows — login → click → assert in one journey (with visual debug)

Scout is a standalone HTTP API with its own keys and credit wallet. Manage keys and billing in My Account → Scout.

What you can call

• Screenshots (single, multi-viewport, pixel diff)
• DOM extract / inspect packs
• Visibility, security, a11y, and tech checks
• DNS, robots.txt, and multi-page crawl (link discovery only — no HTML archive)
• Multi-step journeys (optional per-step debug screenshots) and batch jobs with signed webhooks

Principles

1. Raw data only — Scout reports measurements and nodes. It does not invent rankings or “good/bad” scores beyond expectations you supply (e.g. visibility expect, pixel-diff tolerance). That keeps results auditable and comparable across runs.
2. No content archive — Scout does not store crawled page HTML/text for you. You persist what you need. That limits liability and privacy surface area (no long-lived copy of third-party pages on our side) and keeps Scout focused on verification, not dataset hosting. Short-lived job results and billing metadata are the only exceptions.
3. One public API — Macrocontent uses the same Scout endpoints internally. What you call is what we dogfood.
4. SDK-independent — no Macro CMS selectors inside Scout. Any public URL you are allowed to inspect works the same way.

Start here