We’ve been calling the Monday API for a couple of years now from a few scripts (JS/TS) and since yesterday morning have been receiving errors when querying the API that relate to CORS headers on the host.
The server responds with a 429 response code and the below message:
Access to fetch at ‘https://api.monday.com/v2’ from origin ‘https://monday.com’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
When sending requests via the API playground in-app or postman it works, presumably as these aren’t using a JS client.
Hello @BillyVavlas This looks like a CORS related change on monday’s side rather than anything breaking in your scripts.
The API is still working, but browser based JavaScript requests are now being blocked because the response doesn’t include an Access Control Allow Origin header.
That’s why Postman and server side JS or TS still work. Direct client side calls from the browser aren’t supported and will hit CORS limits.
The usual workaround is to send the request through a backend or serverless endpoint and call the monday API from there.
Dr. Tanvi Sachar
Monday Certified Partner, Monday Wizard
Thanks for your response and suggestions, much appreciated.
I’m aware that the Access-Control-Allow-Origin header wasn’t sent with the response which was causing the browser to block, it’s just not clear what suddenly changed as I didn’t see any communications from the Monday team or any breaking change announcements on the Monday.com developer site (I might have missed it though).
I’ve got a case open with Monday who are investigating, and I’ll update this thread so that others can benefit. Failing that I will take your advice and move the logic to a back-end API and query that from our scripts as a proxy instead.
The script fails when being run as a native JS script file in browser, but primarily we’re using the Monday API within Microsoft Office Scripts (which act as a sandboxed browser).
As mentioned in the original post this seems to be affecting Monday’s own sites also.
I’ve got a case open with Monday.com who are investigating what specifically has changed their side and I’ll update this thread accordingly.
Hi Jonathan, thanks for adding to the conversation, I’m not personally using the monday-sdk-js but it makes sense that it would also be impacted by the issue.
I’ve since heard back from support who have confirmed that this has always been the desired behavior and the fact it was previously working for so long is actually a happy accident for those of us using the API from front-end scripts!
As suggest by others it appears their recommendation is to leverage a back-end service which can act as a proxy between the front-end and their API’s.
Seems fair enough and sensible from a security point of view, but a little surprising as their own sites and JS sdk are also affected so would have expected some better communications on this.
Hi everyone, we wanted to provide an update regarding the 403 and CORS errors some users encountered while using our API JS SDK between Friday, January 9, and today, Wednesday, January 14. Our team has identified the root cause and successfully implemented a fix. Everything is now back to normal, and we apologize for any inconvenience. If you experience any additional issues on this, please open a support ticket.
So Monday.com decides to make a significant breaking change without notifying and sdk users? There is no documentation suggesting an ApiClient class authenticated with a user’s api token cannot make calls from a client side application hosted on monday.com.
I leveraged both seamless and token authenticated sessions to create internal efficiency solutions hosted on monday.com allowing me to display/modify certain data that may normally be restricted from certain users in a workspace.
So my only option is to create a backend endpoint to handle all token authenticated requests and migrate all of my application’s logic?
That’s no problem, but having all of my applications cease to operate as intended without notification and force me to chip away at migration after the fact is frankly brutal.
The playground not working doesn’t make it seem like a happy accident. The fact that it has been working from client-side for so long and now it suddenly doesn’t, doesn’t make it a bug fix but a breaking change. There should have been an official announcement at least
In the same boat as you. Been calling the monday api from browser client for several years with no issue and suddenly stopped working with CORS errors. Have to re-route the request using backend. I’m sure it wasn’t a “happy accident”, it would’ve been returning * for allowed-origins , otherwise it would never have worked. Someone there just realized it and turned it off. Maybe they could have atleast provided an option to “whitelist” specific origins for your api key.
It feels like they don’t know what they want to do with their API.
Every year, specially at the start of the year, there’s breaking changes that force us to change what was working fine, for what feels no real benefit for the end-user.
It is a constant work to maintain an application based on the Monday API.
Do they communicate about the changes? Yes!
But:
First: Not every change is communicated, for example, this one is not on the latest changelog.
Last year I also had another problem with sending files via the API to a file column/update, and that was not on the changelog (at the time at least).
The year before, they changed the API to a non-communicated time, which caught us by surprise (2023-01-16, if my memory doesn’t fail me).
And also recently, they altered the response from the API on the board’s request (only god and the devs knows why). Didn’t change much on the response, but breaks systems that need consistent responses.
This issue was also, not communicated, and was also, ran on a non-communicated time (2025-12-17, at 11:43 AM, GMT -3, caught this on my application logs).
Second: The issue stays the same. I have to continue reading changelogs, continue changing the same applications, for no real benefit. Even if my application just uses ONE request, it is doomed to the API updates.
The problem becomes bigger every time you create something that relies on the API.
Third: They are forcing us to create a middleware to just communicate with the API for a simple query.
That itself brings lots of problems to be solved, like authentication, security, reliability, resources, time, knowledge, IP address.
How do I explain to my client that the system that he relies on every day:
stopped working out of nowhere
it’s not my fault
and now they will need to pay me for an issue that dint exist in the first place.
What if I want, the user, to use a website that uses the Monday API, but I don’t want to make available any middleware to the entire world? Then I’m screwed.
“Just use a VPN” No, why should I? That’s unreasonable.
The issue also goes over the self-hosted applications. Not even applications hosted inside Monday can use the API after this recent update (I’m talking about web apps made by end-users, and hosted on Monday as an application.
Year after year, they add something, next update they deprecate the exact same thing (as the only example that I can remember, settings_str field on columns, because it is recent)
The API is overcomplicated, you have to make multiple requests to get a simple data
The fact that someone had to make a meme about the API speaks for itself. I’ve never seen that in my entire LIFE
These issues are so consistent, happening year, after year, after year, that it makes= me believe they don’t really want us to use the API, neither build applications that rely on it.
Searching for it on this forum, you can see the same issues happening since 2021:
https community monday com/t/api-calls-about-boards-make-no-sense/78811 (removed the dots because for some reason, I can’t add more than 3 links to this post, like that would stop people from doing it…)
Anyway, I’m sorry if I went overboard or if I am mistaken on the rant, but that’s how my experience working with the Monday API has been for the last 3 years.
If you are reading this, and you still want to build something that uses the Monday API, don’t, just don’t.
Thank you for your reply Omer, appreciate the feedback, I’ve also received a response from support stating the same. I’ll test later today and feedback on the ticket and this thread if the issue persists.
Thanks all for weighing in on this topic, Monday support have now responded to my ticket to confirm the issue was their end (no surprise), and not the expected behavior after all..
Quote below from the ticket. (disclaimer, I’ve not tested my scripts yet to confirm it’s resolved, but will do later today and confirm.).
You were absolutely right to question why this stopped working so suddenly without warning. A misconfiguration in our platform-api-gateway inadvertently blocked legitimate traffic (including the SDK and “try-it-yourself” page).
The Resolution: Our developers have identified the root cause and disabled the problematic configuration. The issue is now resolved.
Appreciate everyone’s feedback, and I share all of your frustrations, it’s always worrying when we’re building business critical integrations with key systems and they suddenly stop working without warning.
Hopefully Monday will take all our feedback onboard, especially with regards to better communications of breaking changes or back-end updates that could disrupt service.
Fingers crossed all your integrations are working now, good luck and thanks again!
