CORS

#How CORS works

A page at https://shop.example calls an API at https://api.example. The browser adds an Origin header to the request. The API replies with an Access-Control-Allow-Origin header. If that header does not allow https://shop.example, the browser hides the response from the script.

Requests fall into two groups:

For a non-simple request, the browser asks first with an OPTIONS request. The server answers with the methods and headers it allows. Only then does the browser send the real request.

#Why it matters for AI agents

CORS limits code that runs in a browser page. A script on one site cannot read another site's API response when CORS blocks it. Code on a server is not in a browser, so the same request usually succeeds there. That difference confuses many builders. An agent that calls an API from a backend meets no CORS check. An agent that runs a page script does.

#In practice

Start by asking which side makes the call. If a page script makes it, CORS applies, and the fix belongs on the server. If your own backend makes it, look for other causes, such as authentication or rate limits.

#Related terms

• Same-origin policy
• Cookies and sessions
• Internal API

#FAQ

#Why do I get a CORS error?

The browser blocked a script from reading a response, because the server did not allow the calling page's origin. The error shows in the browser console. Only the server can fix it, by sending the right Access-Control-Allow-Origin header. Changing the page does not remove the rule. A request from your own backend is not subject to it.

#Does CORS protect the server?

No. CORS controls what browsers let scripts read. It is not authentication, and it does not decide who may call the server. The server still has to check every request with its own access controls.