Getting an Item's Updates via API is broken on version 2024-10

Hello there @aholtzhauer,

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?

Cheers,
Matias

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.

Hey @aholtzhauer,

I checked with the team - the higher limit was causing a timeout internally. They deployed a fix for this on Sunday, so you should be good to go!

Best,
Rachel

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!

Thank you for sharing @aholtzhauer !

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?

Hello there @aholtzhauer,

I heard back from the team and the order should be the right one now.

Would you be able to please test it on your end?

Cheers,
Matias

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.

This is bug that should be escalated, please.

[
   {
      "message": "Internal server error",
      "path": [
        "items",
        0,
        "subitems",
        0,
        "updates"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR"
      }
    },
 {
      "message": "Internal server error",
      "path": [
        "items",
        0,
        "subitems",
        1,
        "updates"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR"
      }
    },
    ...
]

Hi @erockx,

Can you please fill out a support request here so the team can take a look at your queries and properly escalate it, if needed?

Thank you!

Best,
Rachel

Already did, #3983988.

^{Trust through Transparency | Progress through Partnership | Change through Community}

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.

Hi @erockx,

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.

Best,
Rachel

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.

Hi @erockx,

Our support team should be reaching out through your ticket!

Best,
Rachel