Added depth functionality to GET /wiki/rest/api/content/{id}/descendant/{type}

UPDATE: This has now been rolled out to 10% production.


What is changing?

Before, the API GET /wiki/rest/api/content/{id}/descendant/{type} would fetch descendants of type {type} at all depths for a content ID {id}. This post is to let you know that we have now added support for an optional depth parameter to fetch descendant:

  1. subpages of a page e.g. GET https:///wiki/rest/api/content//descendant/page?depth=5
  2. end of page comments on a page e.g. GET https:///wiki/rest/api/content//descendant/comment?depth=15
  3. end of blog comments on a blog post e.g. GET https:///wiki/rest/api/content//descendant/comment?depth=2

up to a desired depth.

Why is it changing?

This is to address requests we have received in the past to support this field rather than developers having to fetch all content and do a filtering by depth levels on their side.

What do I need to do?

Please note that depth must be a positive integer up to a value of 100 and if no value for depth is passed in or the passed in value is greater than 100, by default we would fetch descendants of requested type up to a depth 100.

For now we are releasing this support to the developer first release cohort, so please opt in to this if you intend to use this parameter. We will make another announcement when we release this to production.

Note that, if you aren’t in the developer first release cohort, Confluence will continue exhibiting the existing behaviour, which is to fetch descendants of type {type} at all depths for the content ID until we make this feature available in production.

By when do I need to do it?

Since this is an optional field, it’s added functionality and won’t break any existing apps if no action is taken.

3 Likes