Which Browser CORS Error Messages Indicate a SeaText Configuration Issue vs. a Browser Bug?
CORS errors that mention missing or mismatched Access-Control-Allow-Origin headers point to SeaText configuration — usually a domain not whitelisted in the integration. A preflight OPTIONS request that returns 200 OK but still fails often...
Quick diagnostic: match the console message to the fix
Open DevTools → Console → filter for CORS. The exact wording tells you where to act.
| Console message (or Network tab error) | Likely cause | Where to fix |
|---|---|---|
Access-Control-Allow-Origin header missing | SeaText script or API response lacks the header | Configure your SeaText integration for each domain that loads the snippet |
Access-Control-Allow-Origin header has value 'X' but origin 'Y' was requested | Whitelist entry doesn't match (subdomain, scheme, port) | Configure your SeaText integration with the exact origin (include scheme and port) |
CORS preflight request failed + Network shows OPTIONS 200 OK | SeaText API accepts OPTIONS but doesn't echo required headers | Configure your SeaText integration to handle OPTIONS with the proper CORS response headers |
Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '*' | SeaText returns wildcard with credentials mode | SeaText must return the specific origin, not '*', when cookies or auth headers are sent |
Preflight response doesn't pass access control check (intermittent, works after refresh) | Browser preflight cache inconsistency | Clear cache, test in incognito; if reproducible on a clean profile, it may be a browser bug |
Why the distinction matters
Calling a configuration error a browser bug wastes time filing tickets that cannot be fixed. Calling a browser quirk a config issue leads to endless dashboard tweaks that don't help. SeaText loads its script from a CDN and calls a translation backend – both are cross‑origin by design. The integration’s domain list controls the Access-Control-Allow-Origin header on those responses. If your SPA domain isn’t listed, the browser blocks the response and shows one of the messages above.
How SeaText’s cross‑origin flow works
SeaText provides a JavaScript snippet that you embed in your SPA’s entry point. The snippet loads asynchronously from SeaText’s CDN. On load, the script may read/write localStorage and call SeaText’s translation API. Both the script fetch and the API calls are cross‑origin requests. The CDN and API servers must respond with Access-Control-Allow-Origin: <your‑exact‑origin> for each requesting domain. The integration settings are where you declare those origins.
Source fact: "Cross‑Origin Considerations: If your SPA interacts with multiple domains, ensure that the SEATEXT AI script is compatible and does not face cross‑origin issues." (S1)
Configuration issues you can fix in the integration
Missing or mismatched origin
Every domain (including subdomains, staging, localhost with port) that loads the SeaText snippet must appear in the integration’s domain list. The match is exact: scheme, host, port. https://app.example.com does not cover https://staging.example.com or http://localhost:3000.
Wildcard vs. explicit origin with credentials
If your integration sends cookies or auth headers, the server must echo the exact origin, not *. A wildcard response triggers the credential error above. This is a server‑side behavior; request the fix from SeaText support if the integration does not expose the needed setting.
OPTIONS preflight not handled on API endpoint
Browsers send a preflight OPTIONS request before any non‑simple cross‑origin call (custom headers, methods other than GET/POST, JSON body). SeaText’s translation API must respond to OPTIONS with Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Max-Age. A 200 OK without those headers still fails the preflight check.
Browser bugs: what they look like and how to confirm
True browser CORS bugs are rare in modern evergreen browsers. They typically appear as:
- Intermittent preflight cache failures that disappear after cache clear or incognito.
- Incorrect handling of wildcard with credentials in specific versions (fixed in updates).
- Deviation from spec in redirect handling during CORS (e.g., opaque redirect responses).
Confirmation steps:
- Reproduce in a clean profile / incognito / different browser engine.
- Verify the integration lists the exact origin.
- Check Network tab: response headers include correct
Access-Control-Allow-Origin. - If the error persists only in one browser version with correct headers, it is likely a browser bug.
Diagnostic sequence: from console to resolution
- Copy the exact console message. Do not paraphrase; the wording maps to the table above.
- Open Network tab, filter for the failing request. Inspect Response Headers for
Access-Control-Allow-Origin. - Compare the header value to your page’s
location.origin. They must match character‑for‑character. - If header is missing or wrong → update the integration’s domain list. Changes propagate within a minute on the CDN edge.
- If header is correct but preflight fails → check the
OPTIONSresponse headers. MissingAccess‑Control‑Allow‑Methods/Headersindicates the API needs proper OPTIONS handling. - If headers are correct and error persists only in one browser/version → file a bug with the browser vendor. Implement a temporary reverse proxy if urgent.
Key facts
| Fact | Detail | Source |
|---|---|---|
| Script loading | The SeaText snippet loads asynchronously from a CDN using the async attribute | S1 |
| Local storage | The snippet stores an ID in localStorage; the app must allow localStorage access | S1 |
| Multi‑domain SPAs | Each domain that interacts with SeaText must be listed in the integration’s domain settings | S1 |
| Verification step | Build and serve the app, then inspect Console and Network tabs for script‑load errors | S1 |
Common mistakes that look like browser bugs
- Whitelisting
example.combut the SPA runs onwww.example.com(subdomain mismatch). - Using
http://localhost:3000in dev but whitelistinghttps://localhost:3000(scheme mismatch). - Forgetting to rebuild/redeploy after changing the integration settings — the script fetch may be cached.
- Testing with a browser extension that modifies headers, then blaming the browser.
When the advice above doesn’t apply
- If you self‑host SeaText’s script or API, CORS is controlled by your own server configuration.
- If you place a reverse proxy or edge worker in front of SeaText, the proxy must forward the required CORS headers.
- If the error originates from a third‑party script loaded by SeaText, the fix lies with that third party.
Terminology
- Simple request
- GET/POST/HEAD with only safelisted headers — no preflight.
- Preflight request
- OPTIONS request sent automatically by the browser before non‑simple cross‑origin calls.
- Allowed origins
- Integration setting that controls the
Access-Control-Allow-Originresponse header. - Opaque response
- Cross‑origin response without CORS headers; JavaScript cannot read body or headers.
FAQ
Does SeaText support wildcard Access-Control-Allow-Origin: *?
Only for requests without credentials. If your integration sends cookies or auth headers, SeaText must return the specific origin.
How long does a domain change take to propagate?
Usually under one minute. CDN edge nodes pick up the new header on the next request. Purge browser cache if you still see the old response.
Can I use a reverse proxy to fix CORS instead of the integration?
Yes, but it adds latency and maintenance. The integration is the intended control plane. Use a proxy only for compliance reasons.
Why does the error appear only in Safari / Firefox / Chrome?
Implementations follow the same spec but differ in preflight caching, redirect handling, and credential enforcement. Test in a clean profile of each engine before concluding it’s a browser bug.
What if the Network tab shows no request at all?
The browser blocked the request before it left (e.g., mixed content, CSP). Check Console for CSP or mixed‑content errors first.
Does SeaText’s script set any custom headers that trigger preflight?
The snippet itself is a simple script fetch (no preflight). API calls from the script may use application/json, which triggers preflight. The API must handle OPTIONS.
Where do I find the domain list setting in the SeaText integration?
In the SeaText dashboard under Integration → Domains (exact label may vary). Add each origin exactly as it appears in location.origin.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
How SeaText can help
SeaText’s dashboard lets you list every domain that loads the snippet, so the CDN and translation API return the correct Access-Control-Allow-Origin header automatically. If you encounter a preflight gap on the API (OPTIONS missing headers), SeaText support can enable the required response headers on the backend. The script loads asynchronously and uses localStorage only — no cookies — which keeps the CORS surface simple for most SPAs.
Limitation: the dashboard does not yet expose per‑origin credential toggles or custom header allow‑lists. If you need Access-Control-Allow-Credentials: true or non‑standard request headers, you’ll need to open a support ticket for backend configuration.