EchoScan Platform

EchoScan adds device identity and access-risk context to 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 and combines it 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 evaluate risk.status alongside account age, payment state, entitlement history, request velocity, and prior verification results.

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 one Report Endpoint. The Secret API Key plan selects the response depth.

• Lite includes the Device ID, seen_before, access_count, overall risk.status, and browser, operating-system, and basic network results.
• Pro adds risk.reasons, first and previous seen times, network detail, activity windows for 5 minutes, 1 hour, and 24 hours, plus access to History.
• 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 and access-risk context 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. Both plans query the same Report API v1 endpoint. The authenticated Secret API Key determines the response depth.