EchoScan Platform

EchoScan brings device continuity, account-relationship context, and a current-visit assessment into sensitive visits and protected business actions. Browser code collects the current environment and receives a server-issued imprint. The customer’s backend queries the formal Report, keeps device history, account relationships, and current risk in their separate roles, and combines them with account, transaction, entitlement, and verification data.

How a protected action moves through EchoScan

1. A customer administrator creates a Browser Environment in Console and configures exact Allowed Origins.
2. The customer site runs Browser Verifier with the public environmentId.
3. Browser Verifier completes its submission and returns only { imprint }.
4. The site sends the Imprint to its own backend with a login, registration, benefit claim, or other protected action.
5. The backend uses a Secret API Key to query Report API v1 and applies its own allow, challenge, review, or deny policy.

This flow separates the public browser deployment identifier from the protected server credential. It also keeps the final business decision inside the customer’s system.

What runs in the browser

Browser Verifier runs on the customer site. It reads groups of browser, device, and network-environment signals, submits an encrypted request, and receives a server-issued Imprint. The environmentId can appear in browser code. EchoScan uses it to find the Browser Environment and checks the request Origin against its exact allowlist.

Secret API Keys and Workspace IDs stay out of browser code. An Environment ID cannot query a Report or authenticate a protected server request.

What belongs on the customer backend

The customer backend receives the imprint with the protected action, loads a Secret API Key from its server runtime or secret manager, and queries the unified Report Endpoint. It can review device continuity and optional Account Map relationships alongside the current visit’s risk.status, account age, payment state, entitlement history, request velocity, and prior verification results. Device history and account counts do not automatically change risk.status.

EchoScan does not return a customer recommended_action. Registration, login, benefit claims, and high-value transactions can require different policies for the same risk status. The customer system owns the final action because it has the complete business context.

What Report API v1 returns

Lite and Pro use the same base Report structure, covering device continuity, current-visit risk and reasons, browser, operating system, network, and recent activity. Optional fields depend on available signals and data.

• Lite and Pro both support History and optional Account Map, including new links and existing snapshot reads. Pro provides higher request allowances, rate limits, and Browser Environment capacity. History queries a specified time range; the continuity summary and recent activity in the base Report are available in both plans.
• Public risk.status values are PASS, SUSPICIOUS, and DECEPTIVE.

The Report exposes stable business-facing fields. Detector names, internal evidence, thresholds, weights, and bypass conditions remain outside the public contract.

Who uses this flow

EchoScan serves SaaS products, AI tools, API platforms, and online services that need device history, account-relationship context, and a current-visit assessment in an existing backend. Security and risk teams can also use it when reviewing repeat registration, multi-account behavior, automation, and risky network access.

End users on a customer site do not need an EchoScan login. Developers and customer administrators sign in to Console when they need to create Browser Environments, manage Secret API Keys, review usage, or manage a plan.

Public Scan and production integration

Any visitor can run the public Scan without creating an account. It provides an interactive first-party view of the current browser environment.

A production integration runs the collection inside a customer site and queries the formal Report from the customer backend. Continue with the developer integration guide when you are ready to connect the flow.

Questions developers ask

Why is the full Report kept out of browser code?

Report queries require a Secret API Key and can contain device, network, and activity context intended for server-side policy. Keeping that exchange on your backend protects the credential and lets you combine the result with account, transaction, and verification data.

Why can an Environment ID be public while an API Key must stay secret?

The Environment ID identifies an approved browser deployment and is checked against exact Allowed Origins. It cannot read reports. A Secret API Key authenticates protected Report and History requests, so it belongs only in a server runtime or secret manager.

Do Lite and Pro use different Report endpoints?

No. Lite and Pro query the same Report API v1 endpoint and use the same base Report structure. Lite and Pro both support History and optional Account Map, including new links and existing snapshot reads. Pro provides higher request allowances, rate limits, and Browser Environment capacity.