Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.

Why does get_plans API call not return the entries field?


Working on integration of automated test case results with TR and just realized the get_plans API does not have the entries field.

(This is stated in the docs and I found it once I realized what was being returned.)

Wanted to make sure this was not a TR bug. It is not but by design.

Now to get info and work on a specific plan I have to make get_plans call. Loop thru to find the ID I am interested in and make the get_plan API call.

If it is due to an efficiently issue since the entries array field can be large why return all the other data on each plan. Just return the ID and maybe the Name to be used for the get_plan api call.

If one can argue the other data could be useful but not the entries that seems capricious.

Return all (preferred) or just what is needed to make next api call.

Is there something I am missing in use-cases?


Hi Paul,

Thanks for your posting! get_plans only returns those fields that are directly part of the plan such as the name, milestone, description, statistics etc. and you can query additional details via get_plan per test plan. This is for scalability reasons because a test plan can potentially have dozens or hundreds of configurations/runs and it would not be practical to include this for all plans.

I hope this helps!



As I suspected, for efficiency reasons. What is a plan without its runs?

I would suggest the api be renamed to get_plan_ids to make it clear what it does and that it does not return a list of plans.

I have changed my code to reflect this. Now every method to get_elements is the same but the get_plans method.

Thanks for the response.


Hello Paul,

Yep, get_plans returns just the test plan overview if you will and get_plan includes the run related details. Renaming the method and/or changing the scope is difficult without breaking changes but we are happy to look into making this API method more flexible in the future.



Yea, adding another json attribute like all_entries would be good.

I think the most common use case is getting the open plans in a specific milestone which would limit how much data this api call would return. (yes, that is my current case :blush: )

If someone wants to get all the plans in a project I am not sure if they would want the runs or not. They might be doing some data mining on past results and thus would need the runs or doing doing analysis on just the plan data.

But I suspect the common use case would be the former and would they want to look at each test result in every run. Their testing would show if the api call is returning too much for them to handle.


Happy to look into this and thanks for your feedback on this :slight_smile: Definitely makes sense to support this (optionally). Other APIs use the concept of “expands” to include additional related details and we are happy to look into a similar approach for TestRail’s API as well.