Neverming, this works:

query{                

        items(ids: %s){

            updates (limit: %s) {

                id,

                body,

                created_at,

                updated_at,

                creator {

                  id,

                  name,

                  email

                },

                assets {

                  id,

                  name,

                  url,

                  file_extension,

                  file_size

                },

                replies {

                    id,

                    body,

                    creator{

                        id,

                        name,

                        email

                    },

                    created_at,

                    updated_at

                }

            }         

        }

    }

Also see the following syntax. The maximum number of IDs you can specify is 100, same as the using items as the root query. This query is also much more complex from an api complexity standpoint (can’t do as many of them per minute). Its in the thousands to query a board with items_page like this vs tens to do items directly as you did.

query ($boardIds: :ID!], $itemIds: :ID!]) {

  boards(ids: $boardIds) {

    items_page(query_params: {ids: $itemIds}) {

      items {

        id

        name

      }

    }

  }

}

Also I used native GraphQL variables because string substitution handles types poorly.

{

   "query": "graphql string from above",

   "variables": {

      "boardIds": :"12312453252"],

      "itemIds": :"123123","12321", "523432"]

   }

}

@Matias.Monday for you to investigate, since mondayDB changed a lot of things - is the query of items (ids:sID]){} no longer “slower” than querying items within boards (via items_page? The warning saying we should only use items (ids: ID]){} if we have no other options continues to exist in the documentation. However the direct items query is much lower API complexity.

Hello again @anon29275264,

I checked with the team and they said that items_page should be used instead of items{} generally speaking.

items_page is over 4000 complexity just to query a single item. items{} is 25. (with the number of columns I’m testing, as low as 12 if you specify a single column you want rather than all, 12)

Complexity is 4037 for the below. If you forget to set limit to 1 (since there is one ID) the complexity jumps to 4445.

{

  complexity {query}

  boards(ids: "12312312312") {

    items_page(limit: 1, query_params: {ids: "123123123123"}) {

      cursor

      items {

        id

        name

        column_values {

          id

          text

          value

        }

      }

    }

  }

}

Yet the following is 25 complexity to get the exact same data.

{

  complexity {

    query

  }

  items(ids: 5209639007) {

    id

    name

    column_values {

      id

      text

      value

    }

  }

}

Remember, I’m talking in the context of integrations, where I’m only ever getting one item’s values (usually, and if multiple its often across multiple boards)

Hello again @anon29275264,

In the context of a single item, that is the case and I have shared your feedback with the API team so that it can be taken into account.

For anyone retrieviing multiple items, I want to share this article. To save on complexity, you can use the next_items_page object at the root of your query and pass the cursor argument to return the next page.

Cheers,

Matias