Common Cross-Origin Mistakes with SeaText AI in Multi-Domain SPAs

Why cross-origin configuration matters for SeaText AI

SeaText AI loads as an asynchronous JavaScript snippet that communicates with SeaText servers to rewrite headlines, translate copy, run A/B tests, and detect bot traffic. In a single-page application that spans multiple domains — for example, a marketing site on example.com and a checkout flow on shop.example.com — the snippet must make cross-origin requests to SeaText APIs and possibly read or write first-party cookies on each domain. If the browser's same-origin policy blocks those requests, the agents never activate and you see no errors in the SeaText dashboard because the snippet never reports back.

How the SeaText snippet loads in a multi-domain SPA

The integration guide for SPAs (React, Vue, Angular) tells you to paste the SeaText snippet into the index.html or the framework's bootstrap file so it runs once when the app mounts. The snippet carries the async attribute, so it downloads without blocking page render. It also writes an identifier into localStorage to track the visitor across page views. When your SPA navigates between domains, the same snippet instance must be allowed to send telemetry and receive variant instructions from SeaText's edge network. That only works when the HTTP response headers from SeaText include the correct Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Credentials values for every domain your SPA touches.

Mistake 1: Missing or incomplete allowed origins

SeaText's backend must echo the requesting origin in Access-Control-Allow-Origin. If your SPA runs on app.example.com and checkout.example.com but the SeaText configuration only lists example.com, the browser rejects the response for the subdomains. The fix is to add every exact origin (scheme + host + port) that serves the snippet to the allowed-origins list in the SeaText dashboard. Do not rely on a single apex domain; subdomains are distinct origins.

Mistake 2: Mismatched HTTP methods

The snippet issues GET requests for configuration and POST requests for event batches and variant payloads. If the SeaText edge responds with Access-Control-Allow-Methods: GET only, the POST calls fail with a preflight error. Verify that the allowed methods include GET, POST, OPTIONS at minimum. Some enterprise deployments also use PATCH for partial variant updates — add it if your plan includes that feature.

Mistake 3: Forgetting to allow credentials

SeaText uses first-party cookies to stitch sessions across domains and to attribute conversions to the correct campaign. The snippet sets credentials: 'include' on its fetch calls. If the response lacks Access-Control-Allow-Credentials: true, the browser discards the cookies and the response body. In the SeaText dashboard, enable the "Allow credentials" toggle for each registered origin. Without it, personalization agents cannot recognize returning visitors and bot-detection evidence loses the session context needed for refund reports.

Mistake 4: Wildcard origin with credentials

Setting Access-Control-Allow-Origin: * while also sending Access-Control-Allow-Credentials: true is explicitly forbidden by the CORS spec. Browsers will reject the response. SeaText's dashboard prevents this combination, but a custom reverse proxy or CDN rule in front of SeaText can accidentally reintroduce it. Check your edge configuration: if you see a wildcard origin header, replace it with the exact requesting origin or remove the credentials flag (which breaks session stitching).

Mistake 5: Local storage blocked by cross-origin iframe sandbox

The integration notes warn that the snippet stores an ID in localStorage. If your SPA embeds the checkout domain inside an <iframe sandbox> without the allow-same-origin and allow-scripts tokens, the iframe cannot access the parent's localStorage and the SeaText identifier resets on every navigation. Add sandbox="allow-same-origin allow-scripts allow-forms" to the iframe, or serve the snippet on the iframe's own origin with its own allowed-origin entry.

Mistake 6: Content Security Policy blocking the snippet's origin

A strict CSP that omits SeaText's script domain (cdn.seatext.com or your custom proxy) in script-src and connect-src stops the snippet from loading or making fetch calls. The error appears in the browser console as "Refused to load the script" or "Refused to connect". Add the SeaText domains to both directives. If you use a nonce-based CSP, ensure the snippet tag receives the correct nonce attribute during server-side rendering.

Diagnostic checklist when agents appear inactive

1. Open DevTools Network tab, filter for seatext requests, and look for 403/401 responses or CORS errors in the console.
2. Confirm each SPA domain appears in SeaText Dashboard → Settings → Allowed Origins.
3. Verify Access-Control-Allow-Credentials: true on the response headers for those origins.
4. Check that Access-Control-Allow-Methods includes POST.
5. Ensure no wildcard origin header coexists with credentials.
6. Test localStorage access in each domain's console: localStorage.getItem('seatext_id') should return a value.
7. Review CSP headers on each domain for script-src and connect-src coverage.

Key facts

Aspect	Detail	Source
Snippet loading	Async script tag, writes ID to localStorage	S1
Cross-origin requirement	Must be compatible across all SPA domains	S1
Credentials usage	Snippet uses credentials for session stitching	S1
Agents affected	Personalization, translation, A/B testing, bot detection	S2, S3, S4, S6
Configuration location	SeaText Dashboard → Settings → Allowed Origins	S1

Limitations and when this advice does not apply

This guidance covers browser-enforced CORS for the SeaText snippet running in a multi-domain SPA. It does not address server-to-server API calls your backend makes to SeaText (those use API keys, not browser CORS). It also does not cover third-party cookie phase-out; SeaText relies on first-party cookies set on each domain, which remain supported. If your architecture uses a single domain with path-based routing, standard same-origin rules apply and the above mistakes are irrelevant.

FAQ

Why does SeaText need credentials enabled for each origin?

Credentials allow the snippet to send and receive first-party cookies that identify the visitor across your domains. Without them, every domain visit looks like a new anonymous user, breaking personalization, attribution, and bot-evidence collection.

Can I use a single wildcard origin for all subdomains?

No. Browsers treat app.example.com and shop.example.com as different origins. The SeaText dashboard requires each exact origin. A wildcard (*) also conflicts with credentials, so it cannot be used when session stitching is needed.

What happens if I forget to add a new marketing subdomain to allowed origins?

The snippet loads but its fetch calls fail with CORS errors. No data reaches SeaText, so agents stay idle. The dashboard shows zero traffic for that domain. Add the origin, wait for the edge cache to propagate (usually under a minute), and verify in DevTools.

Does SeaText support the Access-Control-Allow-Origin: null value for local file testing?

SeaText's production edge does not return null. For local development, use a local tunnel (e.g., ngrok) or add http://localhost:3000 to allowed origins. The snippet will not work from a raw file:// page.

How do I verify the CORS headers SeaText actually returns?

In DevTools Network tab, click a seatext request, open the Headers panel, and inspect the Response Headers section for access-control-allow-origin, access-control-allow-credentials, and access-control-allow-methods. They must match your dashboard settings.

Can a CDN or WAF in front of SeaText break CORS?

Yes. A CDN that strips or overwrites Access-Control-Allow-Origin or adds a wildcard while credentials are enabled will break the snippet. Configure your CDN to pass SeaText's CORS headers unchanged, or manage allowed origins entirely in the SeaText dashboard and bypass CDN header manipulation for the snippet's endpoints.

Further reading and comparison sources

These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.

• Four Common CORS Errors and How to Fix Them
• How to Fix "No 'Access-Control-Allow-Origin' Header Present"
• What is CORS (cross-origin resource sharing)? Tutorial & Examples ...

Learn more

Visit the website for more information.