[RELEASED] Current status of subitem API support?

Hi, last time I checked about this it seemed that things were quite limited with subitems, so I’d like to get a current answer. It’s my understanding that there’s now a create subitem method. To get all subitems for a board, you must first query all items in a board to retrieve the subitem IDs, and then query the subitem IDs (no way to directly query all subitems in a board). To modify a subitem, you can modify it like you would a normal item, correct?

Thanks in advance.

Hi @jake!

You actually can query all of the subitems on a board using one of two methods:

  1. Query all of the items on the board, then use the “column_values” field to query all of the subitems within that parent item.
  2. Use the above query to find the subitem Id. Use the subitem Id to find the subitem board Id.

Using the second method, you can then query the subitems like you would with a normal item once you have this subitem board Id!

Hi! New user here, probably the same issue - finding relationships between items and subitems. I understand there are two methods:

  1. Retrieve all items of the subitem board, and get the group id field. That id should read “subitem_van_”, so you get the parent of each subitem. Unfortunately sometimes you get “topic”. This problem is explained in another Forum Topic. On my test setup I see some subitems with a correct group, and some subitems with group “topic”.
  2. Retrieve all items of the parent board, and get the column_values. Inside the column_values value is a field with ID “subitems”, and a value consisting of a JSON text with values. Unfortunately in this topic people report they only get a subset of items - just 25, no order was specified. Funny enough I can get 26 subitems without a problem, but I couldn’t find a Forum Topic mentioning the new limit. Also, it seems impossible to request the number of subitems of a parent item, so one can never be sure whether all items were retrieved.

Both referenced topics were closed while still being unsolved, and I cannot find any topic explaining how to get parent-subitem relationships.

In fact, the documentation does not mention reading subitems at all, only creating subitems is discussed. This brings the idea that reading subitems should not be used in production systems using the API. Is that correct?

Hi, welcome to our community!

Happy to clarify our subitem API for you. At this time, as this feature as whole is still in beta, our team is still constructing definitive methods for working with subitems within our API.

I have to say I’ve never run into the 26 subitem limit issue that you’re facing. I just tested this out with 33 items across 3 different items, as well as 31 subitems in a single parent item, and I was able to see all of them in my query. What is this limit referring to? Querying more than 26 items at a time? Or querying more than 26 subitems at a time?

If you’re referring to querying more than 26 items at a time, we do have rate limits for our API. However, you can implement pagination to get past this.

Let me know! Happy to continue digging into this with you.

Hi Helen, thanks for your reply.

I seem to have posted a wrong link in my previous post. A typical newbie error of mine!

Anyway, the limit of returned items in field subitems is mentioned here. The last reaction mentions a “default limit of 25”. This claim was not disputed and afterwards no announcement was made involving this limit. I assume it still exists.

I can get all 26 subitems of a parent item, and you managed to get all 31 subitems of another parent item, so the limit is higher nowadays. Do you know the current limit?

You mention pagination - but I don’t know how to get pagination within a field value. I have the following query:
query request($parentitemid: Int) {
items(ids: [$parentitemid]) {
column_values(ids: “subitems”) {

Can you help me rewrite this, to include pagination and a small page size?

@zweitze no worries!

I believe the 25 item limit is referring to unrestricted item queries (i.e. if you just queried all of your items). Does this make sense?

So if you’re querying your subitems from their board Id, you should implement pagination to return 25 subitems at a time.

To do this, just include the “page” argument for your items. An example would be something like this:

This example returns my list of boards utilizing pagination (so this would return the first “page” of boards in my account!).

The users in that related topic experience a 25-subitem restriction. When issuing a query similar to mine (i.e. querying one column value of one item) they got a response with one field value, as expected. That one field value is a string like
“data”: {
“items”: [
“column_values”: [
“value”: “{“linkedPulseIds”:[{“linkedPulseId”:1111111},{“linkedPulseId”:2222222},
/* …some more items…*/
“account_id”: 1234567

and not all subitems were present in that one value of that one item, due to some limit. How would I work around that? I don’t see how I can use paging within a single value.

I’m not sure that what the end user stated is actually true. There’s no limitation described in our API documentation, so I’m curious to learn why they believe that there is a 25-item limitation. I think they might’ve gotten confused and were referring to the imposed item limitation when you make an unrestricted query of your items on a board.

In this case, the subitems queried would show up as a “Connect” column type (from our UI perspective). As such, there isn’t any limitation as to how many items will be returned for this type of column.

I think the better question would be, how many subitems do you have, and how many is your query returning? I’m assuming you have at least 26 subitems based on your previous response. In any case, if you are running into a limitation issue, please feel free to DM me so that we can continue troubleshooting this as a bug.

This isn’t something that I’ve run into in my own testing (as I was able to return all 31 of my subitems for a parent item successfully in the same format as you posted), and it seems that the thread you’re referring to is quite old so I would assume that performance (and bugs) have gotten better since then.

This group has multiple topics about retrieving subitems, with complaints about missing subitems, you can find another one here (scroll to September messages).
It is possible that those users were trying to do too much in one query, and running out of complexity.

All the time the only explanations offered was that subitems were still in beta - implying that you may not get all when they’re in beta. That would be strange, I would think the API returns all, or nothing, or strange errors, but never a few subitems and no errors.
Once a user suggested the limit of 25, which sounds more like a better explanation for retrieving only part of the subitems. The topics were later closed without contradicting the explanations.

You ask how much subitems I would need. Good question but tough answer. The design here is still in development and my job is also to fill them with data from from our backoffice. I have no maximum, but I guess the maximum will be in the range of 50 - 500.

For me the true issue is ensuring that all subitems are present at the right parent.
If the structure of the API is still be considered, I much more prefer an attribute at the subitem, identifying its parent.

Regarding the closing of topics, our team is trying out a new flow of answering our developer questions within our community. This is something we’re working through, and will be putting out a message once we’ve finalized this workflow of answering tickets. Thank you for your patience in the meantime and for this invaluable feedback!

For the last thread you included, it seems the developer experiencing the issue never got back to the other developer who was assisting. I can say from my own testing though, that this 25 subitem limit seems to be misplaced.

I would say in general, while our developer community is here to help each other out, unless the information originates from a member of the monday.com team, to take the responses with a grain of salt.

I totally understand your last point! I agree that it would make more sense to query the subitem board, and from there, be able to have a field attribute linking the subitems returned back to the parent items from which they sit. This is something our developers are aware of, but still working to build out. I will be sure to add your feedback onto the existing pile. Thank you!

1 Like

We ran into a true problem - when querying the subboard it returned subitems WITHOUT parent items. In other words, when querying the parent board those subitems were not returned. The UI doesn’t show these subitems either. How can these “orphan subitems” exist and how do we deal with them?
account_id: 3133580
Sub board ID: 1014080652
Sub items IDs: 1014080943,1014080754,1014080744,1014080748,1014080722

Also, from a bigger perspective, when subitems get regular non-beta support, how will that be communicated? Can I subscribe to some mailing list?

Thanks for your insights!

Hi @zweitze!

Ahh yes, so if you’re looking to see the connection between subitems and their parent items, I would recommend querying the parent item column_values to see the connection this way.

Here is a thread that outlined this “matching” process: Updating subitems via API.

Great question! In this case, an announcement will be made both in our community, as well as on our API documentation.

If you have any further questions, please consider opening a new thread!

Thank you~

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

Hi @zweitze and @jake!

Happy to announce that we recently released the parent_item field when querying subitems that should help here.