Generated API endpoint #response links do not scroll to the Response section

[chadwallacehart]

Summary

Deep links to the Response section of Fern-generated API endpoint pages do not scroll to that section.

For example:

/api-reference/management-api/reference/history/get-call-history#response

The endpoint page loads and the URL retains #response, but the browser remains near the top of the page instead of scrolling to Response.

This is not specific to Voximplant. The same behavior was reproduced on Fern-generated API reference pages for ElevenLabs, Cohere, Vapi, and Persona.

The behavior occurs in the deployed Voximplant preview and with fern docs dev locally. Both were tested with Fern CLI 4.63.0.

Reproduction

1. Open the DeleteRecord page.
2. Scroll to Query parameters.
3. Under either record_url or record_id, click GetCallHistory.
4. The browser opens GetCallHistory#response.

Expected: The page scrolls to the Response section.

Actual: The page remains near the top at GetCallHistory. The Response section is approximately 3,200 pixels farther down the page, and document.getElementById("response") returns null.

The same result occurs when opening the #response URL directly or refreshing it.

Rendered markup

The rendered page includes an element whose ID contains the complete route and fragment:

<div id="/api-reference/management-api/reference/history/get-call-history#response">
  <h3>Response</h3>
</div>

For a URL ending in #response, the browser looks for an element whose ID is exactly response. It does not match the full-route ID above, so native fragment navigation does not find the section.

Cross-site verification

The same behavior was reproduced on these unrelated Fern-powered API references:

• ElevenLabs — List models#response
• Cohere — Chat V1#response
• Vapi — Create Call#response
• Persona — List all Reports#response

In each case:

• the URL retains #response
• the page does not scroll to the Response section
• no element with id="response" exists
• Fern renders an ID shaped like <route>#response

This strongly suggests that the behavior comes from Fern’s generated API-reference renderer rather than the Voximplant generator or OpenAPI definition.

Related issues

No existing issue was found for this exact behavior.

These issues appear related but cover different cases:

• #16271 — URL # anchors on Tab titles
• #16103 — Sticky H3 headers in API endpoint pages
• #5360 — Some links in API docs display incorrectly when served locally

Questions and requested behavior

Is the full-route ID an intentional public linking contract? If so, what URL or fragment syntax should consumers use to link directly to generated endpoint sections?

Could Fern provide stable fragment navigation by either:

1. Rendering id="response" on generated endpoint pages; or
2. Mapping #response to the existing full-route section ID on the client?