# EchoScan

EchoScan is a device identity and access-risk service. Browser code generates an imprint with Browser Verifier; server-side code uses a secret key to query a Lite or Pro Report API v1 response and make the final risk decision.

Canonical documentation:
- AI integration context: https://echoscan.org/docs/ai-context.md
- Human API guide: https://echoscan.org/pages/developers/api-en-US.html
- Agent API guide: https://echoscan.org/pages/agent-api-en-US.html
- x402-compatible Agent Trial: https://echoscan.org/pages/x402-agent-trial-en-US.html
- OpenAPI 3.1 contract: https://echoscan.org/openapi.json
- RFC 9727 API catalog: https://echoscan.org/.well-known/api-catalog
- Homepage: https://echoscan.org/

Agent Trial:
- Query GET https://api.echoscan.org/api/v1/agent/products before payment. Continue only when agent_trial_lite_100 reports available: true.
- The product is one x402 v2 exact payment for a 72-hour Lite grant and 100 unique Imprint report deliveries. Re-reading the same Imprint is free; failed and missing reports do not consume a unit.
- Its exact capabilities are fingerprint.submit, fingerprint.report.lite, and agent.trial.status.
- Create an intent with one exact HTTP/HTTPS origin, keep the one-time claim token only in process memory, inspect PAYMENT-REQUIRED, and use an official x402 HTTP client to retry the activation POST.
- Intent creation returns product, activate_url, and status_url but no payment challenge. Activate returns only intent_id, status, and status_url; active status recovery delivers trial_id, environment_id, api_key, allowed_origin, quota, expires_at, and report_endpoint as top-level fields.
- Poll the status URL after response loss or uncertain settlement. Do not pay a second time for the same intent.
- The trial key can read Lite reports and its own grant status only. It cannot access Pro reasons, History, Pick, submit-lite, Billing, Console, or internal routes.
- This release describes x402-compatible agent payments. It does not claim Cloudflare Wallets compatibility and publishes no MCP Server Card.

Official product and company pages:
- [About EchoScan | Device Identity Research and Service](https://echoscan.org/pages/about-en-US.html): Learn how long-term Chromium, anti-fingerprinting, and browser-environment research became EchoScan's device identity and access-risk service.
- [Browser Fingerprint API | EchoScan](https://echoscan.org/pages/browser-fingerprint-api-en-US.html): Integrate the publishable Browser Verifier, send its imprint to server-executed code, and query Report API v1 without exposing a Secret API Key.
- [Browser Fingerprinting Explained | EchoScan](https://echoscan.org/pages/browser-fingerprinting-en-US.html): Learn how browser fingerprinting combines environment signals, why results change, and how EchoScan separates Browser Verifier imprints from server-side risk reports.
- [API Key Abuse Prevention | EchoScan](https://echoscan.org/pages/api-key-abuse-en-US.html): Add device continuity and access-risk context to free API quota and developer-trial controls without treating one repeated device as proof of abuse.
- [Device Continuity Before Login | EchoScan](https://echoscan.org/pages/device-continuity-en-US.html): Understand how EchoScan adds seen-before, access-count, timestamps, activity, and History context to visits before login or account creation.
- [EchoScan Platform | Device Identity and Access Risk](https://echoscan.org/pages/platform-en-US.html): See how Browser Verifier, your backend, and EchoScan Report API v1 work together to add device identity and access-risk context to protected actions.
- [Browser Fingerprint Research and Methodology | EchoScan](https://echoscan.org/pages/research-en-US.html): Read the public methodology, reproducibility principles, testing limits, and boundary between published research and internal detection rules.
- [EchoScan Privacy Policy](https://echoscan.org/pages/privacy-en-US.html): How EchoScan handles browser, device, network, account, workspace, API-key, usage, session, and subscription data across public and customer-integrated services.
- [EchoScan Terms of Service](https://echoscan.org/pages/terms-en-US.html): Terms for EchoScan public pages, Console accounts, Browser Environments, Secret API Keys, usage plans, SDKs, reports, subscriptions, and customer risk decisions.
- [Trial Abuse and Multi-Account Risk | EchoScan](https://echoscan.org/pages/trial-abuse-en-US.html): Use device, browser, network, automation, and continuity context to review repeat trials and multi-account resource abuse without treating one repeated device as proof.
- [EchoScan Agent API](https://echoscan.org/pages/agent-api-en-US.html): Discover the product catalog, OpenAPI contract, RFC 9727 API catalog, security boundaries, and machine purchase flow.
- [x402-compatible Agent Trial](https://echoscan.org/pages/x402-agent-trial-en-US.html): Purchase and recover a short-lived Lite evaluation without exposing payment or API credentials.

Packages:
- Browser Verifier: @echoscan/browser-verifier
- Node server SDK: @echoscan/echoscan
- Go server SDK: github.com/echoscan/echoscan-go
- Python server SDK: echoscan
- Rust server SDK: echoscan

Integration boundary:
- For a new Workspace, enter one website URL in Console. EchoScan atomically creates its Web App, exact Allowed Origin, and default server API key. Copy the publishable Environment ID.
- Save the server API key shown by the successful setup response. The plaintext secret appears once and belongs only in the server runtime.
- Install Browser Verifier and configure it with the publishable Environment ID.
- Generate an imprint for the protected action and send it to server-executed code.
- Use that key to query GET /api/v1/fingerprint/report/{imprint}; the authenticated key plan selects Lite or Pro depth.
- Read risk.status and, for Pro, risk.reasons. Apply the customer's own allow-or-challenge policy and return only the minimum result to the browser.

API key lifecycle:
- The first website setup creates the Workspace default key. Later keys can be created independently from the authenticated EchoScan Console API Keys page.
- The plaintext secret is returned only in the successful creation response. Save it immediately in a server environment variable or secret manager.
- Revoking a key immediately stops it from authenticating new protected requests. Create a replacement key before revoking an in-use key when rotating credentials.

Primary report fields:
- `risk.status`
- `risk.reasons (Pro)`
- statuses: PASS, SUSPICIOUS, DECEPTIVE
- Pro product reasons: BROWSER_VERSION_MISMATCH, BROWSER_IDENTITY_MISMATCH, OS_ENVIRONMENT_MISMATCH, AUTOMATION_DETECTED, ENVIRONMENT_INCONSISTENT, PROXY_DETECTED, HOSTING_NETWORK_DETECTED, NETWORK_INCONSISTENT, LOCATION_INCONSISTENT, SIGNAL_DATA_INCOMPLETE

Rules for coding agents:
- Read the AI integration context before editing an application.
- Do not invent EchoScan package names, report fields, endpoints, or response shapes.
- Use the publishable Environment ID in Browser Verifier; never send a Workspace ID from browser code.
- Create and manage Browser Environments separately from secret API keys; do not read an Environment ID from an API key payload.
- Do not put EchoScan secret keys in browser code, frontend environment variables, localStorage, logs, git, or public files.
- Never place a buyer private key, claim token, PAYMENT-SIGNATURE, or Agent Trial API key in a URL, prompt transcript, log, metric label, browser storage, or committed file.
- Do not infer production price, asset, network, facilitator, or pay-to address from test fixtures. Treat the live product catalog and payment challenge as authoritative.
- If the target app structure is unclear, inspect the repository first and ask a concise question before changing the integration boundary.