Rate limit/ Retry-After header value too large

[Yajat Grover]

Why is Atlassian rate limiting my selective requests. When I try to fetch confluence content on page using REST API, it works but when I am trying to download attachments on that page, it says Rate Limit Exceeded.

Even when I try ConfluenceLoader from LangChain it says Retry-After header value too large - OverFlow error.

This URL works:

f"{CONFLUENCE_URL}/rest/api/content?title={PAGE_TITLE}&spaceKey={SPACE_KEY}&expand=body.storage,version"

This URL of downloading attachments results in Rate Limit exceeded error:

f"{CONFLUENCE_URL}/rest/api/content/{page_id}/child/attachment"

Response headers for failed URL:

'X-RateLimit-Limit': '0', 'X-RateLimit-Remaining': '0', 'X-RateLimit-FillRate': '0', 'X-RateLimit-Interval-Seconds': '1', 'Retry-After': '9223372036854775807'

Why do I have these as headers, why is RateLimit 0, why do some endpoints work, some results in rate limit exceeded/overflow error.

Can anybody explain why is this happening? 

[MeghnaP_LogicLemur Labs]

Great explanation by @Aron Gombas _Midori_ ! Just adding a bit more context that might help.

The X-RateLimit-Limit: 0 you're seeing is actually a known behaviour — a value of 0 doesn't mean "zero allowed", it typically means the limit is being enforced at the org/tenant level rather than per-endpoint, and the header is surfaced inconsistently depending on which rate limiting batch that endpoint falls under. Aron's right that not all endpoints were rolled out simultaneously.

The Retry-After: 9223372036854775807 is effectively Long.MAX_VALUE in Java — which means the system is telling you to wait indefinitely. This often happens when you've hit a secondary rate limit (burst protection) rather than the standard quota, and those tend to be much stricter on attachment-related endpoints since they're more storage/IO intensive on Atlassian's backend.

A few practical things to try:

• Add exponential backoff with jitter on attachment fetches specifically
• Fetch attachment metadata first, then download sequentially with a deliberate delay between each
• Check if your Confluence plan/tier has any API consumption limits — some plans have tighter ceilings than others

On that last point — if you want visibility into how much of your API quota is actually being consumed across your instance, there are some apps on the Atlassian Marketplace that tracks your API quota and worth checking out to give you real-time quota usage and rate limit monitoring dashboards. Might help you understand where the pressure is coming from before you hit the wall.

Hope this unblocks you!

[Kh_Safal]

@MeghnaP_LogicLemur Labs, this topic has been locked because the thread has become a bit dated. To keep discussions easy to follow, please start a new topic for any related questions or updates. You can read more about necro posting (“raising threads from the dead”) in our Community Guidelines.
Thanks!

[Aron Gombas _Midori_]

@Yajat Grover 

Yea, rate limiting is a PITA. All app developers are fighting with them.

This is the most important related documentation: https://developer.atlassian.com/cloud/jira/platform/rate-limiting/

About why different end-points behave differently? I recall that rate limiting was introduced in multiple batches, each batch covering a selection of REST API end-point. I can even imagine that certain, less critical end-point are still not rate limited...