Attempting to get an item’s updates via GraphQL has broken with the rollout of version 2024-10.
This query would work on version 2024-07, but now does not work. Please try it on the API Playground:
query {
items(ids: [itemIdHere]) {
name
updates(limit: 40) {
creator {
name
}
}
}
}
This same query works fine even with about 190 columns on a board:
query {
items(ids: [itemIdHere]) {
name
column_values {
id
value
text
type
}
}
}
For the first query, lowering the update limit to something like 20 or 25 causes the query to execute properly. Previously in version 2024-07, you could request something very large like 300 updates in one request and it would run just fine.
Why has this functionality been changed? What is the proper process for getting all updates from an item now?
That is odd. I ran the query on my end and it works fine.
Would you be able to please fill this form adding as much information as possible to it (such as account ID, board IDs, item IDs, timestamps, etc.) so that our team can take a look into it?
The issue actually appears to have been resolved as of this past weekend (was still broken Friday but is working now!). The only change it seems that was made in Monday’s API is that when getting Updates, if there was an update created by a Monday automation, the creator is now null, with no fields attributed to it (name, photo_thumb_small, etc)
I’ll go ahead and code around that for now, but I’m not sure if it’s intended or not.
For anyone else reading this thread - know that if you’re getting updates via the API, the creator parameter will indeed be null for an update posted by a Monday Automation, but the creator_id parameter should return -4 for an Automation.
Other than that, everything should be good to go now!
Sorry to revive an old topic, but… does anyone know why in version “2024-10”, getting updates from an item returns the updates in order from earliest created to last created, as opposed to the default style in “2024-07” and earlier where the first update returned would be the last/most recent update? Is there a way to flip the order retrieved when making the GraphQL request?
The documentation on this page here: (Updates) states “Updates are returned in descending order (newest ones first)”. This holds true when grabbing updates universally from a board, but when grabbing updates from an item, the updates are retrieved in reverse order now. Was this an intentional change?
This seems to be happening again. I’ve tested the query below with 2025-01, 2025-04, and 2025-07 over the API and in the Playground. In every case, the updates response is null. No difference if I add a limit to updates either.
It is SUPER important to our usage of Monday.com that we can retrieve updates using the API. Can someone please look into this ASAP?
{
items(ids: [123456789]) {
id
name
column_values {
id
text
column {
title
}
}
subitems {
id
name
column_values {
id
text
column {
title
}
}
updates {
created_at
body
}
}
}
}
I just notice that my response via API or Playground, contains this error for every subitem returned. So something with the updates are erroring out in Monday.com, but the response returns the rest of the data found.
I’ve received ZERO response from the support ticket. I can’t imagine this is only happening to me. My GQL query is super simple and there have to be tons of customers that have items with subitems with updates. Is your entire engineering team putting out this fire and unable to communicate? I’m super confused how no communication about what seems to be a system-wide failure is the right call here.
I’m apologize for the delay - I know our support team is trying to work through a backlog and responses are taking longer than normal.
I myself can’t seem to replicate the error you’re getting. I copied the query you provided, changed the item ID, and am getting a successful response for all of the requested fields (across all versions). Are you still having this issue? If so, does it consistently return an error?
The good news is that it likely means it isn’t a bug! However, this could indicate an issue with something you’re querying and might require looking at your specific board/items.
Yes, this is still happening. While I concede it may be specific to my account, I am getting actual instances of “INTERNAL_SERVER_ERROR” in the response. Therefore, you must be able to see what the actual error is in your logs. Also, because this is an uncaught error, I have to believe it is affecting others.
I can also confirm that another query returned null for the “subitems” column value of an item, even though that item had subitems.
Because this problem seems to only occur when using a multi-level query (i.e. items > subitems > updates or items > subitems), I can work around it by using multiple queries with just one level (i.e. get all sub items, then use each subitem to get its updates).
If you have so many uncaught errors that this isn’t even on your dev team’s radar, I’m starting to question the quality of Monday as a product.
