Changes to Content APIs max number of sub-expansions in the `expand` query parameter

What is changing?

We will be limiting the number of sub-expansions allowed in the expand query parameter of the Get Content by ID API (/wiki/rest/api/content/).

The maximum sub-expansions will be set to eight (8). That means that API calls with an expand query parameter with more than 8 sub-expansions will receive an error. Sub expansions are expansions beyond the first one. For example,

expand=children.page.children.page.children.page.children

has 6 sub-expansions and is OK under the new limit, but

expand=children.page.children.page.children.page.children.page.children.page.children

has 10 sub-expansions and will return an error when executed.

Why is it changing?

Complex and nested expand query parameters create performance issues, which can affect the whole instance.

What do I need to do?

Use the Get content descendants API (/rest/api/content/{id}/descendant) instead to get all the child pages.

Timing

This change will be rolled out by the end of July, 2021 .

3 Likes

Hi @rtalusan,

just to clarify if I understand this correctly: The new limit will only apply to nesting depth of individual expansions, but not to the overall expansions?

Can you confirm that the example below (split lines for easier reading) will continue to work because the nesting limit isn’t reached in any of the individual expansions?

history.lastUpdated,
space.icon,
space.description.plain,
metadata.labels,
children.attachment.history.lastUpdated,
children.attachment.metadata,
metadata.properties.propa,
metadata.properties.propb

Thanks,
Jens

2 Likes

Hi @jens,

Yes, that’s right. The new limit will only apply to nesting of individual expansions. And the example you listed will still continue to work, and there shouldn’t be any changes related to that.

Ryan

2 Likes