Access-Control-Allow-Origin header value


Many of our clients use WordPress as the platform for their main company websites. When building landing pages and blogs etc on HubSpot, one challenge we have consistently faced is navigation - specifically that the menus have to be maintained in two places - in a HubSpot coded file (include) and also on WordPress.

Hence, we have started using the WordPress API to grab the menu items from the main site and build the menu in HubSpot dynamically. Landing pages that we have created are on subdomains of the main domain where the WordPress install resides, so cross origin requests are not needed.

All works OK 90% of the time, but we have intermittent issues where the request to the WordPress API is rejected based on the value of the Access-Control-Allow-Origin header being sent as rather than the landing page URL. As I said, it’s not all the time - but when it does happen the user viewing the page has no navigation! Obviously we can have a fallback where we use some static code, but I’d like to understand how/why this is happening.

For clarity, these are LIVE landing pages, not being previewed or using any preview links.

Thanks in advance.



@craigivemy How are you making those requests/API calls? When the Access-Control-Allow-Orgin header is being sent that is usually an indication of someone trying to make a front-end request to HubSpot. For security reasons we only allow server-side requests to our APIs.


Hi @pmanca - the request is being made via AJAX - but the request isn’t to the HubSpot API (which I know does not support AJAX requests), but to the WordPress API.


@craigivemy Ok got it. Does this happen on live HubSpot pages that are published or on a staging domain?


@pmanca these are live pages. No preview URLs, fully live pages on a subdomain of the main domain that hosts the site we connect to to get the menu items.


@craigivemy thanks for the info. I’ll reach back to the COS development team and see if I can get any clarity. Before I do that can you link me the page that I can share with them as an example.


Sounds good, thanks.

Example url is

As I said, this issue is intermittent (but is present on other portals and LP’s too), and most of the time it is OK. I was thinking perhaps it’s related to editing the template recently, or perhaps being signed in and with Design Manager open or something - but having said that I can’t actually find a way to trigger it - just seems random.



@pmanca any luck with this? Cheers


@craigivemy Sorry for the delayed response. We were all hands on deck last week with our Inbound Conference.

This is an issue with caching. When you preview the website, it makes the api call under, so the response has access-control-allow-origin set to When you open up the page, the response is cached for the preview site, not for the live site, hence why it doesn’t load. It won’t affect any of your customers

To be safe, you can add "Cache-Control" : "no-cache" in the request header
But then you will lose the benefit of caching


Hi @pmanca - no worries I thought that might be the case. We had a few from our agency over in Boston.
Not sure I’m following how this is being cached though.

I just loaded this page and I was seeing the error. I cleared all cache, loaded in incognito, in 3 different browsers and also sent to 3 colleagues, all of whom were visiting this page for the first ever time and they are also seeing the error and the missing menu.




@pmanca just to let you know I’m now loading the menu statically when the API request fails, but the error will still be logged in the console along with ‘Menu loaded statically’


@craigivemy did you add that header? The cacheing would be on our CDN side and not on the client side. When I look at the logs I still see the request being sent from hs-preview sites.


@pmanca sorry did I add which header?


"Cache-Control" : "no-cache"


@pmanca ah sorry no I hadn’t yet - I’d prefer not to if possible. Not sure I understand exactly how this is happening.

At what point is the header being sent as in the first place? When somebody edits the page within HubSpot?

If it’s sent as then, when the page is viewed live with the live URL - why would it be using a cached response from a totally different URL (the edit page URL) and from a new person/IP/browser etc? As I said, when it wasn’t working yesterday (you’ll see it now is working) - people who had never viewed the page before were getting the error.




Hey Craig,

So the Allow-access-control-origin is set by the server (in this case the site on wordpress) to restrict access to the API. If you are hosting a public API, it is a good idea to restrict who can have access to API through setting this header, preventing cross-site scripting attacks

As an example, imagine you were running a bank API on that can perform banking operations for clients. Now imagine there is a website that one of your clients visits while he/she is currently on in another tab. On the malicious site, it makes a call to the bank api to transfer money from your client’s account to some other account. If the bank api had the Allow-access-control-origin header set to wildcard *, the request would go through. However, if the Allow-access-control-origin header is smartly set to, then the request will be rejected because the origin of the request,, is not allowed access.

In this case, you are hosting the wordpress API on the wordpress domain, but calling it from a site on the HubSpot domain. In order to allow your HubSpot site access to this API, you must add a header to your api responses within WordPress: Allow-access-control-origin: You can see how others have done this here: I believe this will resolve your issue.



Hi @Matthew_Coley thanks for the message - I am aware of Allow-access-control-origin headers having built a couple of API’s myself and will not be adding a wildcard for obvious reasons.

However, the request should be coming from ‘’ - where the HubSpot page is hosted.

But some of the time, it get’s sent as, NOT This is the problem.




Hi Craig,

I did some research this morning, and it seems like CORS may be busted for WP API according to this issue: Which version of the API are you using?



It seems like a temporary solution would be to add a random query param at the end of the API request ?random={randomlyGeneratedNumber}, which should prevent caching.


Hi @Matthew_Coley not sure what they repo is for but that (closed) issue is a year and a half old - WP API was still being developed as a plugin at that point.