We just added a new breaking change to API version 2023-10:
The deprecated items field on the groups object will be removed and replaced with items_page in API version 2023-10 . Please see our previous announcement for more information about the items_page field.
Uuuuuuuuh. Whoa. This is all becoming a little too real here.
So are you telling me that at a certain time less than a year from now (the rolling dates have me a little confused), if I run a query using the “items” field, even though it has worked 1000s of times before, it is suddenly going to give me an error?
And I have to go under the hood of all my GraphQL queries that I have running in Make.com and update them to use items_page???
I know right, this sounds a bit crazy. Also “page” field will no longer work, making items_count a bit redundant.
Hi @MSIlydia,
Our apologies for the delayed response.
You are correct that the items field on groups (and boards) will not work in version 2023-10 and beyond. You will instead need to use items_page. This change comes due to updates to our infrastructure that now allow for larger boards. You can read more about that here.
Regarding dates, version 2023-07 (the last version that supports the items field) will be completely removed on January 15th. Any calls using the items field at that point will not run.
We are working with the developers at Make to update their platform with the new version. We are still waiting to confirm whether or not Make end-users will need to update their workflows.
@Kofi I see what you mean. items_page utilizes the limit and cursor arguments instead of page to paginate through data sets, though the default limit/the ability to set your own limit makes items_count redundant. Either way I will pass your feedback along to our API team 
Thanks for your response. I have just spent some hours learning the new items_page system to work with my Make.com automation, and for non-coder like myself was a bit painful.
It especially did not help that while this is now the default API, there isnt a way to set headers or use items_page in Make.com. A Make.com specific HTTP module could help.
I used the standard HTTP module with Make as a work arround. However, because the structure of output between next_items_page and items_page are different, iterating through the items in both cases was not fun.
Fingers crossed something more useable comes along, because I can see this being a nightmare explaining this and liaising with clients that have had working automations in place for years.
I’d like to get ahead of this change asap.
Thanks for the feedback Kofi! Make is currently adapting their modules to work with the new API, and I’ll pass your feedback along to our contact there 
I have been involved in a discussion in the make community and the impression I got from their response is that they are going to release a NEW monday app and module set. This is a poor choice because its going to force every make & monday user to recreate every scenario with the new set of modules.
There is very little changing that will actually break outputs of existing modules, the most likely break point is if there is make routing around a column type and the ColumnType enum is different (and I suspect this is going to be a rare scenario because most of the time the columns in use are static so no decision needs to be made on the column type). Everything else just requires internal changes (specifically around items_page) to get the same outputs.
Also they have yet to do what you and I discussed and that’s let the Execute GraphQL Query module specify the API version. This is forcing all make/monday users into a corner. The window to modify all of the custom queries is closing quickly. All partner created scenarios are going to require partners to “update” them - and there won’t be enough time do anything.
At the very least if they are going to go with the new app in make, they should release the Execute GraphQL Query (the simplest module to adapt) as the first module in the new app ASAP.
Hey Cody – don’t be so sure about that. I’m working with Make to update their modules such that there’s minimal migration needed.
I cannot promise what exactly migration will look like, but I am advocating for as smooth a transition as possible!
Thanks!
Any chance they’re open to at least letting us specify API version on the Execute GraphQL Query module in advance of the final new version?
The custom queries are what worries me the most right now - since if the new version isn’t released until November or December, then we’re pretty much down to a couple weeks to migrate several hundred scenarios across customers with the holidays in there.
Will bring it up with them!
The feedback I have been getting from make.com is similar to @codyfrisch–the transition will not be seamless, and there will/may well be modifications made to existing scenarios.
I agree with Cody, the window between the new version, third party’s (Make) ability to react, and us an end-user is tight to keep everything running smoothly.
Cody, could you share the HTTP code, including header information you were able to get to work to specify the version to make your own calls to Monday.com?
I’ve been a bit stymied in trying to do my own testing/work around.
