Feature Request: Allow clients to invalidate their own documentation cache

[pdonorio]

Description

Clients currently have no way to trigger cache invalidation for their own documentation.
This requires reaching out to Fern support manually, which adds latency when docs need
to reflect recent changes immediately.

Use case

When documentation is updated (e.g. new API pages go live), the cache may serve stale
content. Clients cannot self-serve a cache bust — they must rely on Fern support to
reset it on their behalf.

Proposed solution

Expose a client-accessible mechanism (e.g. a button in the Fern dashboard, or a CLI
command / API endpoint) that allows authorized users to invalidate the cache for their
own docs namespace.

Why this matters

• Reduces dependency on Fern support for routine cache resets
• Faster feedback loop when deploying doc updates
• Low implementation lift per Fern's own assessment

Additional context

This came up during an incident (01KJWQKRRW4RHHQZA3E2TMBFSR) where stale cached pages were served after the incident was resolved. Having a self-serve cache invalidation option would reduce the recovery time in similar situations.

Environment

• Fern docs platform (cloud-hosted)

[briankwest]

Can you elaborate on what you're seeing? I think we are seeing the same thing.

[pdonorio]

Can you elaborate on what you're seeing? I think we are seeing the same thing.

which part needs elaborating? what are you seeing? @briankwest

[briankwest]

What are you seeing, We seem to be having random 404s and we're told its related to cache too, wanted to know if you see that too?

[pdonorio]

@briankwest Our issue was different — after a Fern incident was resolved, previously cached pages continued serving stale content. We had to ask Fern support to manually reset the cache before the updated pages appeared.

So ours was stale cache persisting too long, rather than 404s from missing cache entries. Likely distinct root causes, but both point to wanting more client control over cache lifecycle.