Skip to main content

Hey guys,


We are working on API 2024-01 migration because it offers a higher limit when it comes to items_page query (500 in 2024-01 against 100 in 2023-10).


You can see it clearly documented in the graphQL Schema and API Docs


items_page(

    "An opaque token representing the position in the result set from which to resume fetching items. Use this to paginate through large result sets."

    cursor: String,

    "The maximum number of items to fetch in a single request. Use this to control the size of the result set and manage pagination. Maximum: 500."

    limit: Int! = 25,

    "A set of parameters to filter, sort, and control the scope of the items query. Use this to customize the results based on specific criteria."

    query_params: ItemsQuery

  ): ItemsResponse!

Buuuuuut, when we set limit parameter to 500 and use query_params .ids to set more than 100 item ids we get an error:


INVALID_ARGUMENT_EXCEPTION: Invalid request: the number of provided IDs cannot exceed the limit of 100

This is confusing, what’s the benefit of increasing the limit to 500 while limiting the number of IDs to 100 ? 🤔


How can we get 500 items in one call using their IDs ?

Makes perfect sense – seems like it slipped someone’s mind

Hey @Matias.Monday, do you have any information from your side on such limitation at query_params.ids level of items_page ? Can’t find any documentation related to this 🥲

Hey Khalfa,

Fetching items by ids is always limited to 100 items, I will pass on this feedback so we make it more clear in the items_page documentation that this will happen too as is deatiled for items query here:

GraphQL API

I will say though that it looks like using the items query passing ids would be better for your use case, although it’s also limited to 100 - worth looking into 🙂

There really needs to be an improvement in documentation that if you have item Ids to use the items root query. I can think of only one use case for using item IDs with items_page: you want to filter within a set of item IDs. All this talk about nesting items inside boards being “faster” never made sense if you have specific IDs you need (totally legit for purposes of returning unknown items for a board!). Its still the same items query resolver in both cases, and nesting it inside boards just means boards has to get executed first. If you need board info AND a list of items by ID just put boards and items both at the root of the same query!

Hello there @anon29275264,


I will share your feedback with the team 😁


Cheers,

Matias

Reply


Terms & ConditionsCookie settings