Confluence Cloud: contentbody/convert/async returns empty result for TOC macro - known issue?

In a simple test setting, I’m converting a table of contents macro to export_view format, using the contentbody/convert endpoint.

This works well, using the synchronous (but deprecated) contentbody/convert endpoint. It does not, using the asynchronous contentbody/convert/async endpoint.

Here’s my test page’s storage XML:

<ac:structured-macro ac:name="toc" ac:schema-version="1"
    ac:macro-id="d968a3d8-3d77-4313-9a7a-1644222a69bc">
</ac:structured-macro>
<h1>Heading 1</h1>

Using the deprecated contentbody/convert/export_view endpoint, the result is something like this:

<style type='text/css'>snip</style>
<div class='toc-macro rbtoc1739281782416'>
    <ul class='toc-indentation'>
        <li><a href='#id-2025-02-11T14:49:35_96Page0-Heading1'>Heading 1</a></li>
    </ul>
</div>

Using the recommended async contentbody/convert/async/export_view endpoint, the result (after GETting it via contentbody/convert/async/JOBID) is:


                
            

Yes. That’s pretty empty.
Status of the job is COMPLETED, no error message.
Are there known issues with the async contentbody/convert endpoint?

Edit: Other macros seems to work (tested with profile) - might be an issue specifically with the table of contents macro.

Edit2

Thinking about this more, the issue might be that the deprecated endpoint respects the content part of the payload that establishes a page context for the conversion, while the new endpoint might not.

My request body looks like this:

{
  "content": { "id": "524289"},
  "value": "<xml>",
  "representation": "storage"
}

The content ID is crucial to establish page context.

The new API has a contentIdContext query parameter. Using that it works.

How simple was that??

1 Like