Domain verification & session trust

Before this system existed, ARCY treated any origin you typed into a settings field as trusted. Nothing checked that you actually controlled it. In practice this meant two problems: your AI credit budget wasn't fully protected from a third party who never touched your dashboard, and CORS was a hardcoded list of ARCY's own domains, so a real customer's own production site could fail to bootstrap a session at all.

Domain verification and signed session tokens close both gaps. This page explains the concept; see the dashboard Manage > Settings > Verified origins card for the actual flow.

Proving you control a domain

Verification works the same way most providers prove domain ownership for a certificate or a custom domain: you add a DNS TXT record, and ARCY's backend looks it up.

1. In the dashboard, go to Manage > Settings > Verified origins and add an origin (for example https://myapp.com).
2. ARCY generates a token unique to that origin and your app, and shows you the exact DNS TXT record to create: name _arcy-verify.myapp.com, value the generated token.
3. Add that TXT record with your DNS provider (Route 53, Cloudflare, GoDaddy, etc.). Propagation is usually fast, but can take up to a few hours depending on your provider's TTL.
4. Once it's live, click Verify in the dashboard. ARCY looks up the TXT record and checks it matches.

An origin you've added but haven't verified is stored, so you can see it's pending, but it is never trusted for anything. It doesn't pass CORS, and it can't bootstrap a session. Only a verified origin unlocks those.

Verification is entirely DNS-based and per-hostname: nothing to add to your source code, and nothing shared between subdomains. Verifying myapp.com never conflicts with or invalidates verification for app.myapp.com — each hostname carries its own independent TXT record and its own verified state.

www and your bare domain are treated as the same origin

https://myapp.com and https://www.myapp.com share the same verification token and the same verified status — verify either one and both are trusted for CORS and session bootstrap. This is the one exception to exact hostname matching: it only strips a leading www., nothing broader. https://app.myapp.com or any other subdomain is a fully separate origin with its own TXT record and its own verification step.

In practice this means you only ever need to add and verify one of the two — pick whichever your production site actually serves traffic from. You don't need a redirect between them for ARCY's sake (though one may still be worth adding for SEO, to avoid duplicate-content indexing — that's a separate concern from domain verification).

Why this replaced the old allowed-origins list

The previous allowedOrigins setting was a plain list of strings an admin typed in. An empty list meant "allow everything," which was convenient for local development but meant a freshly created app had no real protection until someone remembered to lock it down. The new model inverts that: an app with zero verified origins rejects every session bootstrap by default. There's no accidentally-wide-open state.

Signed session tokens

Session bootstrap (ARCYProvider mounting in your app) now returns a short-lived, signed token bound to your app and the verified origin that requested it, not just a bare session ID. Every other SDK call — chat and autopilot queries, event tracking, page views, session end — has to present that token, and the backend resolves which app it's billing from the token itself, never from a value the caller supplies in the request body.

Practically, this means a request can no longer claim to belong to your app by guessing or copying a session ID. It has to be holding a token that only your own verified, already-bootstrapped app session could have received. Every issued token and every request that consumes one is written to an audit trail, so a billing dispute can be traced back to exactly which origin and session generated it.

None of this requires any code change on your part — it's handled inside the SDK you already have installed. It matters if you're auditing why a session isn't bootstrapping (check that the origin is verified) or investigating unexpected credit usage (check the audit trail for the session and origin it came from).

Related

• API key security: how your publishable and secret keys fit into this