# A CORS Mismatch That Broke DocMind AI on a Fresh Netlify Deploy

> Source: <https://dev.to/codewithurooj/a-cors-mismatch-that-broke-docmind-ai-on-a-fresh-netlify-deploy-published-79c>
> Published: 2026-07-23 10:35:52+00:00

*This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.*

[DocMind AI](https://docmindaichatbot.netlify.app) is a RAG-based document chatbot — you upload documents and ask questions about them, and it retrieves relevant context and generates grounded answers. The stack: FastAPI backend, Groq LLaMA 3.3 for generation, Pinecone for vector storage, HuggingFace embeddings, and a Netlify-hosted frontend, with voice input/output built on top.

The backend already had CORS configured correctly in principle — `CORSMiddleware`

was in place, scoped to a specific origin rather than a wildcard, with `allow_credentials=False`

and an explicit method/header allowlist. That part was never the problem.

The actual bug was a domain mismatch. The frontend had been redeployed to a new Netlify site, `docmindai-chatbot.netlify.app`

— note the hyphen — while the backend's `allow_origins`

list still only contained the old domain, `docmindaichatbot.netlify.app`

, without the hyphen. Two names that look almost identical at a glance, but the browser treats them as completely different origins. Every request from the new deployment was blocked before it reached the API, while the old domain kept working fine — which made it easy to miss at first, since "the app works" and "the app works from the URL I'm actually testing" turned out to be different claims.

Commit: [291e6d8 — Update CORS to allow new Netlify domain](https://github.com/uroojbuilds/Docmind-Ai/commit/291e6d85541181e9ae388b8d2285a766089e93c5)

Before:

```
allow_origins=["https://docmindaichatbot.netlify.app"],
```

After:

```
allow_origins=["https://docmindai-chatbot.netlify.app", "https://docmindaichatbot.netlify.app"],
```

Full block, unchanged parts included for context:

```
app.add_middleware(
    CORSMiddleware,
    allow_origins=["https://docmindai-chatbot.netlify.app", "https://docmindaichatbot.netlify.app"],
    allow_credentials=False,
    allow_methods=["GET", "POST", "OPTIONS"],
    allow_headers=["Content-Type", "Accept"],
)
```

Repo: [uroojbuilds/Docmind-Ai](https://github.com/uroojbuilds/Docmind-Ai)

Live demo: [docmindai-chatbot.netlify.app](https://docmindai-chatbot.netlify.app/)

The fix itself is a one-line addition, but the useful part was figuring out it was a CORS problem specifically, and not a broken deploy. The browser's network tab showed requests failing with no `Access-Control-Allow-Origin`

header, while the backend logs showed nothing at all for those requests — which is the classic CORS signature: the browser blocks the request before your server code ever runs, so there's nothing to catch in a `try/except`

or print statement. If the API were actually down, curling it directly would have failed too; instead, curl worked fine and only the browser call from the new Netlify URL failed, which pointed straight at an origin allowlist problem.

Rather than loosen the config to `allow_origins=["*"]`

— which would have made the symptom disappear immediately — I kept the existing narrow, explicit list and just added the missing domain. The backend already had `allow_credentials=False`

and a tight `allow_methods`

/`allow_headers`

list, which is good practice for a public API even without cookies in play, and a one-off deploy mismatch isn't a reason to give that up for convenience.

The lesson that's stuck with me: Netlify doesn't guarantee it'll reuse the exact site name you expect on every deploy, and a CORS allowlist has to track the *actual* deployed origin, not the one you assumed you'd get. Now when I redeploy the frontend, checking the live URL against `allow_origins`

is one of the first things I verify before calling it done.