Confluence REST API v2 needs ability to fetch multiple content properties, plus missing attachment trash

Confluence Development Confluence Cloud
1

Hi Atlassian team,

The REST API v2 was recently upgraded with the ability to fetch multiple content objects (pages, blogposts, etc) with one API call.

There are still some holes:

  1. The docs say that multiple comma-delimited IDs can be provided when fetching multiple content items. Is there an explicit or implicit limit to the number of items that we can request in the comma-separated list? If so, can this please be documented?

  2. While the “fetch multiple content ids” feature is now implemented for pages and blogposts, the V2 API is missing the ability to fetch multiple attachments with one call.

  3. Apps equally need the ability to fetch multiple content properties (of whatever type) with one API call. We used to be able to do this quite simply using expansions, but now we are forced to make a single request for each individual content piece that might have a content property. This is slow and cumbersome.

  4. On a completely separate topic, we are currently able to untrash an attachment using this API call, which is now deprecated. I do not see any replacement in V2. Do you have plans to remedy this?

Thanks,
Scott

4 Likes
2

:wave: Hi @scott.dudley,

Thank you for the feedback here!

  1. There are currently explicit but undocumented limits on our endpoints that have these ID filters - we will get the limits bumped up and standardized to be 250 + add this to our documentation.
  2. Good callout - we will make sure to release a Get attachments endpoint soon!
  3. Given our move to more strongly typed “content” - pages, blog posts, attachments, etc. and their corresponding granular OAuth 2.0 scopes, this means we are keeping our endpoints separate based on type/corresponding scope. However, we will work on delivering a set of endpoints for getting multiple content properties per type, example: Get content properties for pages. This will at least resolve the paint point of making a request per piece of content.
  4. Thanks for the heads up here - we will work on an Update attachment endpoint that will contain the ability to change the status of an attachment.
3

Hi @SimonKliewer,

I just wanted to see if there are any updates on when the above proposed APIs are expected to get shipped? We are getting close to six months out from the proposed Jan 1 drop-dead deadline for the REST v1 API, so it would be great if we could know when we will be able to schedule the required work.

Thanks,
Scott

3 Likes
4

Hi @scott.dudley - thanks for the follow up. We are targeting a release in early July that should resolve the issues you are seeing here!

For:

  1. Will be included in upcoming release (Early July)
  2. Will be included in upcoming release (Early July)
  3. Work for this recently started, it might not be ready by above release but will be ready soon after
  4. Instead of introducing a new V2 endpoint, I wanted to check if this non-deprecated V1 endpoint would work for you.

You could use the following body:

{
  "id": "<id-here>",
  "type": "attachment",
  "status": "current",
  "version": {
    "number": <current-version+1-here>
  }
}

Hopefully this helps - thanks so much!

1 Like