CORS headers missing on api.heigit.org — browser requests blocked from browser-based client

openrouteservice
1

Hi,

Following the deprecation notice for api.openrouteservice.org, we have been updating our integration to the new api.heigit.org domain. However, we are hitting a CORS issue that blocks all browser-based requests to the new endpoint.

Error observed:

Access to fetch at ‘https://api.heigit.org/openrouteservice/v2/directions/driving-car/geojson’
has been blocked by CORS policy: Response to preflight request doesn’t pass access control check:
No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

Our setup:

POST requests are made directly from the browser (no server-side proxy) to /v2/directions/driving-car/geojson
Origin: https://nissy6.pasientreiser.nhn.no
The identical requests work correctly against api.openrouteservice.org
This looks like a configuration gap in the migration — api.openrouteservice.org sent Access-Control-Allow-Origin headers that allowed browser clients, but api.heigit.org does not appear to do the same.

Could CORS headers (Access-Control-Allow-Origin) be added to api.heigit.org to support browser-based requests? We have already submitted an upgrade request and are ready to migrate fully before the August 2026 shutdown, but are currently blocked by this issue.

Thank you for your time.

Deprecating "api.openrouteservice.org" in favour of "api.heigit.org"
2

Hey,

sorry for your troubles, and thank you for letting us know!

We are looking into it and will report back here once we have resolved the issue.

Best regards

1 Like
3

Hey,

from our side, things look like they should:
OPTIONS-request to api.openrouteservice.org:

$ curl -X OPTIONS -i "https://api.openrouteservice.org/v2/directions/driving-car/geojson" -H "Authorization: *****" --json '{"coordinates":[[8.681495,49.41461],[8.686507,49.41943],[8.687872,49.420318]]}' -H 'Accept: application/geo+json' -H 'Origin: thisisatest'

HTTP/2 204
server: nginx/1.25.4
date: Mon, 11 May 2026 09:26:54 GMT
access-control-allow-origin: *
access-control-allow-methods: OPTIONS,GET,POST
access-control-allow-headers: Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Authorization, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers
access-control-max-age: 1728000

OPTIONS-request to api.heigit.org:

$ curl -X OPTIONS -i "https://api.heigit.org/openrouteservice/v2/directions/driving-car/geojson" -H "Authorization: ****" --json '{"coordinates":[[8.681495,49.41461],[8.686507,49.41943],[8.687872,49.420318]]}' -H 'Accept: application/geo+json' -H 'Origin: thisisatest'

HTTP/2 200
server: nginx/1.25.4
date: Mon, 11 May 2026 09:26:00 GMT
content-length: 0
accept-patch:
access-control-allow-origin: *
access-control-expose-headers: Access-Control-Allow-Origin, Access-Control-Allow-Credentials
allow: POST,OPTIONS
strict-transport-security: max-age=63072000; includeSubdomains;
vary: Origin,Access-Control-Request-Method,Access-Control-Request-Headers
x-ratelimit-limit: 2000
x-ratelimit-remaining: 1993
x-ratelimit-reset: 1778575002
strict-transport-security: max-age=63072000
x-content-type-options: nosniff
x-frame-options: DENY
access-control-expose-headers: x-ratelimit-limit, x-ratelimit-remaining

Note, that absence of the Origin header indeed implies absence of the CORS headers:

$ curl -X OPTIONS -i "https://api.heigit.org/openrouteservice/v2/directions/driving-car/geojson" -H "Authorization: ****" --json '{"coordinates":[[8.681495,49.41461],[8.686507,49.41943],[8.687872,49.420318]]}' -H 'Accept: application/geo+json'

HTTP/2 200
server: nginx/1.25.4
date: Mon, 11 May 2026 09:26:17 GMT
content-length: 0
accept-patch:
allow: POST,OPTIONS
strict-transport-security: max-age=63072000; includeSubdomains;
vary: Origin,Access-Control-Request-Method,Access-Control-Request-Headers
x-ratelimit-limit: 2000
x-ratelimit-remaining: 1992
x-ratelimit-reset: 1778575002
strict-transport-security: max-age=63072000
x-content-type-options: nosniff
x-frame-options: DENY
access-control-expose-headers: x-ratelimit-limit, x-ratelimit-remaining

If you still experience issues, please do submit a full HTTP request, ideally in an easy-to-reproduce way such as a cURL request. It is quite hard to debug these issues without concrete examples of what request was sent and what happened.

Best regards

4

Hi Jakob, (Don’t mind the “-” instead of “.”, forum blocks me from posting more than 2 URL’s..)

We found and fixed the path issue on our end — we were using /v2/… instead of /openrouteservice/v2/… on api-heigit-org. However, after correcting that, browser requests to api-heigi-org are still blocked by CORS.

The root cause: the OPTIONS preflight response from api-heigit-org is missing the access-control-allow-headers header. A browser request includes Authorization and Content-Type in Access-Control-Request-Headers, but since the preflight response doesn’t explicitly allow these, the browser blocks the actual request.

Compare:

api-openrouteservice-org (works from browser):
access-control-allow-headers: …, Authorization, Content-Type, …

api-heigit-org (fails from browser):
access-control-expose-headers: Access-Control-Allow-Origin, Access-Control-Allow-Credentials
(no access-control-allow-headers)

We are staying on api.openrouteservice.org for now. Could you add Authorization and Content-Type to access-control-allow-headers in the CORS preflight response on api.heigit.org?

Best regards
Alf Einar

1 Like
5

Hey,

thanks again for pointing us to this issue.

I have posted an update here:

Any other update on this will follow there as well :slight_smile:

1 Like
6

Hey,

as stated in the other thread, CORS should now work on api.heigit.org.

Please remember that Access-Control-Request-Headers should be a

sorted list of unique, comma-separated, lowercase HTTP headers
as per the MDN Web Docs.

If you still experience issues, please share the full request that causes them, ideally as a cURL-request.
You should be able to copy that from the web dev tools of most common browsers - at least FF and Chrome have that.

Best regards

7

Hi, confirming that CORS is now working correctly for us on api.heigit.org/openrouteservice/v2/.

We’re making POST requests from a browser-based client with Authorization and Content-Type headers, and the preflight is passing without issues.

Thanks for the quick fix!

1 Like