Your website rollout, from setup to support.

1. Agree the handoff

Name one implementation owner on your team and one rollout owner at Snared. Choose one workflow first: login, signup or account recovery. Send the exact HTTPS test origin, your backend/CDN stack, expected test volume, and any existing routes under /assets/ or /events/.

Your completed package includes handoff.json and wrangler.jsonc. The public settings are SNARED_PUBLIC_ORIGIN, SNARED_UPSTREAM_ORIGIN, SNARED_TENANT_ID and SNARED_SURFACE. The only service credential needed by this adapter is the separately delivered SNARED_API_KEY, held on your server. Snared retains its own governance/operator credentials.

Supply your website's published privacy notice URL. The generated rehearsal page links to that notice; the kit does not create or host a privacy notice for you. Confirm the link works before collection. The Snared privacy notice explains Snared's service separately.

Do not guess an SDK hostname, reuse the Snared-owned pilot tenant, or copy its private Cloudflare service binding. The client adapter uses the HTTPS upstream supplied in your handoff. The starter supports login, signup and recovery; a checkout or other high-risk action needs an agreed server-context adaptation.

2. Install on a dedicated test origin

The downloadable kit contains a Cloudflare Worker adapter, a consent page, a browser lifecycle, a configuration file and a full README. Use it on a dedicated, registered test hostname. It is a reference for other server platforms; Node, Next.js and other frameworks need the same boundaries implemented in their existing backend.

1. Review the assigned settings. Confirm the exact origin and tenant with Snared. The hostname needs an active Cloudflare zone accessible in the selected account. Ensure the test hostname and Worker name are unused. Resolve any existing CNAME with your DNS owner before proceeding. Never deploy the kit's whole-site wrapper over an existing site.
2. Install the pinned tooling. Use Node.js 22.13 or later, run the commands below in the extracted directory, and verify the Cloudflare account. Keep the generated lockfile for repeatable installations.
3. Keep the credential server-side. After Snared confirms admission for the rehearsal, enter the credential using the secret prompt, then deploy the reviewed test Worker. Secret updates can create a deployment; check the target Worker first.
4. Open the registered HTTPS origin. No SDK collection should occur until you agree and start the test. A local HTTP preview is not a test against the live Snared tenant.

npm install
npx wrangler login
npx wrangler whoami
npm run check

# Only after the assigned test origin and admission are confirmed:
npx wrangler secret put SNARED_API_KEY
npm run deploy

The local dry run checks packaging. It does not create your Snared tenant or prove credentials, DNS, retention, privacy readiness or remote availability. Follow the package README if your login sees multiple Cloudflare accounts.

Adding this to an existing site

Mount the adapter's exact route allowlist in your existing router and keep all other application routes intact. Reserve the SDK's same-origin paths, including /assets/metrics.js, /assets/m, runtime chunks and the declared /events/ routes. Add POST /internal/snared/assess to your backend. Do not use a blanket forwarding rule that captures unrelated assets, cookies or credentials.

Keep your authentication, CSRF checks, rate limits and existing security controls. Adapt the consent page to your own notice and collection choice. Retain the tested browser lifecycle and the server verification checks. For a real business workflow, bind the event and verified result to the authenticated session and operation on your server; a browser result is not authority to complete a separate action.

The page uses same-origin external scripts and styles with a restrictive Content Security Policy. Resolve CSP and route conflicts deliberately; do not add unsafe-eval or disable your policy to hide an integration error. Dynamic bootstrap/events, assessments and verification must not be cached. Cache SDK assets only according to their returned cache policy.

3. Verify the complete flow

1. Consent and collect. The page loads the SDK once. The SDK creates a real event and uses its one-shot ingest grants.
2. Wait for the final upload. Preserve event_id, accept only terminal collection success, and wait for successful final signal ingest. A preliminary blackbox is not a final result.
3. Assess on your server. The browser sends only {event_id, blackbox} to your backend. Your backend fixes the tenant and simulation context and calls Snared with its server-held credential.
4. Verify on your server. Your backend remotely verifies the returned token, checks tenant, event, surface, assessment, policy and effective action, and returns a limited verified summary. The assessment token stays off the page.

Success in the starter reads Integration verified and includes verified: true, simulation: true, an assessment ID and trace ID. An HTTP 200, a decoded token, a score, or a successful ingest alone does not establish this result.

{
  "verified": true,
  "simulation": true,
  "assessment_id": "<issued assessment ID>",
  "event_id": "<the SDK event ID>",
  "trace_id": "<issued trace ID>",
  "effective_action": "allow_observe"
}

This ordinary Worker/CDN path is indirect. It does not attest the visitor's TCP, TLS, HTTP/2 or p0f fingerprint. Forwarded headers cannot reconstruct those browser connections.

When the answer is pending or unavailable

The reference browser gives the combined server request 30 seconds. The adapter bounds body parsing, assessment and verification separately. A timeout can occur after work has committed, so it does not prove that the server stopped.

A retryable pending or lost response allows one manual retry after 30 seconds with the exact event and blackbox held in page memory. It does not recollect or automatically retry. The service may replay an existing assessment or make another authorized attempt; this is not a guarantee against rescoring. A returned verification failure keeps available diagnostic IDs and does not trigger reassessment. A second unknown outcome stays unavailable. Never retry a consumed ingest grant.

Unavailable does not mean verified allow. During shadow rollout, preserve your existing controls and the agreed unavailable behavior; do not silently bypass them or start blocking users based on this trial.

4. Accept together, then expand deliberately

Snared prepares the tenant, origin registration, retention roster, deletion coverage and authorized release. Your team owns the website integration and its notice, session binding, application controls and operational configuration. Both teams sign off on the actual test origin.

• One consenting test completes collection, final ingest, assessment and verification with matching IDs.
• No SDK traffic precedes consent; no service credential, assessment token or raw blackbox appears in browser reports, tickets or ordinary logs.
• Foreign-origin, wrong-tenant, malformed and forged-token tests are rejected without becoming verified results.
• Pending, timeout and verification-failure behavior follows the agreed recovery policy; no automatic collection or retry loop occurs.
• Snared completes governed deletion/minimization of the owned test subject and verifies tenant retention coverage, with an unaffected control.
• A working monitored privacy channel, published website notice, named support owner and escalation route are confirmed.
• Both sides record the package/version, tested browsers, observation period, stop criteria, and authorization/SDK renewal owner.

Rehearsal → limited shadow cohort → broader shadow trial. Each transition requires a recorded decision by both owners. The supplied kit remains simulation-only. Moving to real visitor observation requires review of your application-specific session binding and server-owned context, fresh tenant acceptance and the privacy gate; it is not enabled by changing a browser flag. Keep current controls and compare integration latency, unavailable rates and business-flow impact against the agreed baseline. No fixed rollout percentage or success threshold is assumed.

Pause new collection if credentials appear in the browser, an origin or tenant boundary fails, verification unexpectedly fails, removal/retention work is unresolved, or the agreed availability/latency threshold is exceeded. Use the existing application path while Snared investigates. Do not erase records or weaken guards to clear an acceptance failure.

Troubleshooting

Support, privacy and ending the trial

Use the named support and privacy channels in your completed handoff. Send the test time and timezone, website origin, browser/OS, assessment ID, trace ID, displayed error code, duration and reproduction steps. State the business-flow impact. Do not send credentials, tokens, blackboxes, raw signals or another person's identifiers. Disable body capture on these routes in logs, APM and session replay tools.

Read the Snared privacy notice alongside your website's notice. Automatic expiry runs in bounded hourly batches; unfinished work carries forward. Configured application retention does not establish provider log, trace, analytics or backup retention. There is no geographic residency commitment, and exports are unavailable in this trial.

For removal, your operator verifies the request and scopes it with Snared to the correct tenant. An assessment ID can help locate a record but is not proof of the requester's authority. Snared uses the governed removal workflow and verifies its outcome.

To end or pause the integration, stop new SDK collection and assessment calls, retain your existing application controls, and ask Snared to retire the tenant's credential/origin through its change process. Agree the handling of submitted records and retain a minimal closure receipt. Removing the script does not delete data already submitted.

Cloudflare setup references: server secrets, custom domains and Worker configuration. These describe platform setup; Snared admission and acceptance remain separate.