Retrieving cards recursively. Possible?

	"include_membership_statuses": [1, 2],
	"parent_card_id": 8b1aae6f-ef78-4cc0-a205-7203c07c1157,

This request body will return the ids of all the children of the card with id “8b1aae6f-ef78-4cc0-a205-7203c07c1157”: there are six in my case.
Is there a way to specify retrieving cards recursively: all the children of the card with id “8b1aae6f-ef78-4cc0-a205-7203c07c1157” and their sub children etc? (twelve in my case).


IMO I think it would be better to make the recursive call on the client side for the time being, as this could be a potentially expensive operation and a possible vector for abuse. Long term it may be better to support this recursive behavior in the API, but to me it makes sense to do this once the API is a bit more mature.

This sounds reasonable, but are you sure about the expense of the operation? (I’m not an expert here, just out of curiosity!)

I have not yet looked for the details of the recursive implementation on the client side, but I think it is something like this:

  • instead of retrieving the list of card IDs I should retrieve full details for each card in question (including body and all the whistles)
  • parse the response to find if held_total_child_count is not equal to 0 and then retrieve the full info for children cards as well etc…

Is it really less expensive for the server, than just running a server-optimised routine to give user a list of requested card IDs?

So I think what @thomasdotred was talking about (and this is actually pretty spot on) is not that one is cheaper than the other but that providing an option for it encourages the behavior.

We generally don’t want users to reflexively reach for recursive queries when they are fetching cards, as they are fairly expensive.

That being said, this is a feature we want to add, and has actually been something we’ve thought about from the beginning. When we do though, it will probably be restrictively rate-limited so that you can only make so many recursive requests per minute or such.

1 Like

Thanks for the clarification. I’m especially interested in recursive queries because of the lack of multi-card editing in the current SN state (no easy way to change tags, colours, parents for a multiple cards at once).