Why does your browser send an OPTIONS request before your API call?

Most developers encounter CORS errors at some point while building modern web applications — especially when a SPA talks to microservices hosted on different domains.

But very few actually understand what really happens under the hood.

When a browser tries to call an API on another origin, something interesting happens before the real request is even sent.

A silent negotiation begins.

The browser first sends a preflight request to the server asking questions like:

• Which HTTP methods are allowed?
• Which headers can be used?
• Are credentials permitted?
• Is this origin trusted?

Only after the server answers correctly does the browser allow the actual request to proceed.

This mechanism is called Cross-Origin Resource Sharing (CORS) — and it’s one of the most misunderstood pieces of modern web security.

In my latest write-up I break down:

✔ Why the Same-Origin Policy exists
✔ How CORS enables microservices architectures
✔ What really happens during a preflight OPTIONS request
✔ The meaning of the critical Access-Control- headers*

If you build APIs, microservices, or SPAs, understanding this flow can save you hours of debugging.

👉 I’ve shared the full deep dive for supporters here