GET /wiki/api/v2/inline-comments returns 404 on one Cloud site while/wiki/api/v2/footer-comments returns 200 - same site, credentials and scope

Confluence Development Confluence Cloud
1

Hello,

We integrate with Confluence Cloud via a scoped API token and the
api.atlassian.com gateway. On one customer site, the site-wide inline-comments
collection endpoint returns 404 unconditionally, while the equivalent
footer-comments endpoint on the same site returns data normally. We would like
to understand why, and what the supported alternative is.

ENVIRONMENT
Site cloud id : <SITE_CLOUD_ID>
Base URL : https://api.atlassian.com/ex/confluence/<SITE_CLOUD_ID>/
Page scraping is fully independent of the comment map. An empty map costs nothing there — pages scrape normally. The code already uses GetValueOrDefault(spaceId, Empty), so an empty map is a shape it handles by design.

The site-wide inline call is only used for discovery — working out which pages have new inline comments. ts are fetched.

Inline comments themselves are fetched per page, and that works (200). Your cmdlet run proved it: for page 2476539923, GetPageCommentsAsync called both pages/{id}/footer-comments and pages/{id}/inline-comments, both 200, plus ~10 inline-comments/{id}/children. So any page that gets discovered has its inline comments collected.

So what’s actually lost
Only pages whose sole recent change is a new inline comment — no page edit, no new footer comment. Those that comment is missed until something else brings the page into scope.

This only holds if the failure is caught inside ListCommentsBySpaceAsync, around the await foreach, so the parents already collected from the footer phase are kept. The footer phase yields its batches before the inline phase throws.

The naive version — wrapping the whole ListPagesForCommentsAsync call — would discard the footer results too, and that would mean no comments at all. Worth being explicit on the ticket, because it’s an easy way to get the fix wrong.

So: not “ignore inline comments forever.” More like “lose comment-only discovery for inline comments, while still collecting them wherever a page is scraped for any other reason.” For Plaid that’s academic until the profile-visibility permission is granted, since users-bulk blocks comment fetching regardless — but for the general resilience fix, it’s a small, well-bounded degradation rather than dropping a feature.

✻ Churned for 57s

❯ if a page does have an edit, will it bring its comments as well? will it also run the ScrapePageCommentsAsync with the ProcessMultiThreadKnowledgeSourceCommentsAsync in it? or only fetch the comment data?

Sharp question — and I may have overclaimed. Let me check whether the document path fetches comments at all.

Searched for 3 patterns, ran 1 shell command

You were right and I was wrong. Both answers are worse than I said.

  1. A page edit does not bring its comments. ConfluenceKnowledgeSourceServiceScrapeSpaceDocuments.cs contains zero references to comments. The two paths are completely separate:
  • ScrapeSpaceDocumentsAsync → pages only
  • ScrapePageCommentsAsync → comments only, driven exclusively by commentParents from the site-wide discovery pre-pass
    So my “inline comments are collected for every page discovered via page edits” was simply false. There isto its comments.
    2. Yes, it runs the full feedback pipeline. ScrapePageCommentsAsync calls ProcessMultiThreadKnowledgeSoureKnowledgeSourceServiceScrapeComments.cs:48) — so it’s not just fetching comment data, it’s thedeveloper-reply routing path.

Which means your original framing was correct

With site-wide inline discovery failing, an inline comment is only ever collected if the same page also has recent footer-comment activity (which is what would put it in commentParents). Otherwise it’s never picked up — not “until something else brings the page into scope,” because nothing else does.

And because the comment path is also the feedback path, what’s lost isn’t just comment records — it’s developer replies made as inline comments never being routed into Clover. For context, feedback shows 860 ConfluencePage rows across 28 tenants, so Confluence comments are a live feedback channel, not a nicety.

So the honest position on failing soft: it’s still the only way to unblock pages, and it’s still worth doing for that reason and to stop one endpoint taking down all Confluence ingestion. But it is not a benign degradation — it permanently drops inline-comment discovery, including inline developer feedback, for any affected site.

That changes what should go on the ticket. Rather than “fail soft and accept the loss,” the options worth weighing are:

  • Fail soft — pages recovered, inline-comment discovery lost.
  • Fail soft + per-page inline sweep — when discovery is unavailable, fetch inline comments for pages scraped in that run via pages/{id}/inline-comments, which works (200). More requests, but recovers the discovery gap.
  • Fail soft + push Atlassian — accept the gap short-term, treat the 404 as a support case rather than a permanent condition.

The middle option is probably the right one, and it’s only viable because per-page inline-comments works. Worth noting ConfluencePageOnDemandScraper.cs:117 already calls ScrapePageCommentsAsync, so there’s precedent for driving comment scraping from a page rather than from site-wide discovery.

I’d want to check how expensive that sweep is before recommending it properly — one extra call per scraped page per run. Want me to look at the volume?

✻ Sautéed for 59s

❯ preapre an email that i’ll send to atlassisan support for this. make sure no customer data is there

Here’s the email. I’ve scrubbed all customer identifiers and left placeholders where Atlassian genuinely can’t act without them.

Subject: GET /wiki/api/v2/inline-comments returns 404 on one Cloud site while
/wiki/api/v2/footer-comments returns 200 — same site, credentials and scope

Hello,

We integrate with Confluence Cloud via a scoped API token and the
api.atlassian.com gateway. On one customer site, the site-wide inline-comments
collection endpoint returns 404 unconditionally, while the equivalent
footer-comments endpoint on the same site returns data normally. We would like
to understand why, and what the supported alternative is.

ENVIRONMENT
Site cloud id : <SITE_CLOUD_ID>
Base URL : https://api.atlassian.com/ex/confluence/<SITE_CLOUD_ID>/
Auth : scoped API token, HTTP Basic
Granted scope : read:comment:confluence (among others)

FAILING REQUEST

GET https://api.atlassian.com/ex/confluence/<SITE_CLOUD_ID>/wiki/api/v2/inline-comments
/api/v2/pages/{id}/inline-comments 200
GET /wiki/api/v2/inline-comments/{id}/children 200
GET /wiki/api/v2/inline-comments 404 ← the problem

Per your documentation, GET /inline-comments and GET /footer-comments accept
identical query parameters (body-format, cursor, limit, sort, status) and
require the same scope, read:comment:confluence. On this site one returns data
and the other 404s.

WHAT WE HAVE ALREADY ELIMINATED

  • Query parameters. We tried the bare endpoint with no parameters, plus
    limit=1, limit=50, sort=-modified-date, status=open, status=resolved, and
    body-format=storage. All nine variations return the same 404.

  • A specific record or data volume. limit=1 also returns 404, so no result
    can be retrieved at all and the failure is not tied to a particular
    comment.

  • Authentication and authorisation. Other endpoints on the same site, with
    the same token in the same session, return 200 — including per-page
    inline-comments and inline-comment children, which carry the same
    documented scope requirement.

routing. We see the identical 404 whether the request goes to
api.atlassian.com/ex/confluence/{cloudId}/ or directly to the site domain.

  • A general API problem. Four other Confluence Cloud sites we integrate with
    issue this same request with the same parameters and do not receive a 404.
    The behaviour is specific to this one site.

RELATED OBSERVATION

The v1 equivalent for enumerating comments site-wide also fails on this site:

GET /wiki/rest/api/content/search?cql=type=comment

HTTP/1.1 403 Forbidden
{“statusCode”:403,“message”:“…CQL was parsed but the search manager was
unable to execute the search. Error message: …There was an illegal request
passed to XP-Search Aggregator API : HTTP/1.1 403 Forbidden”}

So site-wide comment enumeration appears unavailable on this site in both API
versions, while per-page comment retrieval works in both.

QUESTIONS

  1. Why does GET /wiki/api/v2/inline-comments return 404 on this site when
    GET /wiki/api/v2/footer-comments succeeds with the same credentials and
    scope?

  2. Is this endpoint gated by a site setting, plan or entitlement, or by a
    staged rollout? If so, which, and can it be enabled?

  3. Is the 403 from the v1 CQL comment search related to the same underlying
    restriction?

  4. If site-wide inline-comment enumeration is not available on this site, is
    there a supported way to discover pages with recently modified inline
    comments without iterating every page individually?

Happy to provide HAR captures or run further requests on request.

Thanks