OpenAPI 3.1.0 webhooks key not server-side rendered

[RichardBray]

Problem

Pages that reference an OpenAPI spec using the webhooks key (OpenAPI 3.1.0) are not server-side rendered. Only the paths key is serialized in both SSR and markdown content negotiation (Accept: text/markdown).

This means webhook API reference pages appear empty to LLMs, agents, and any non-browser client.

How to reproduce

# paths-based page — returns full spec ✅
curl -s -H "Accept: text/markdown" 'https://docs.firecrawl.dev/api-reference/endpoint/map' | head -30

# webhooks-based page — returns empty paths: {} ❌
curl -s -H "Accept: text/markdown" 'https://docs.firecrawl.dev/api-reference/endpoint/webhook-crawl-started' | head -30

The map page references an OpenAPI spec with paths, so the full schema is returned. The webhook page references a spec using the webhooks key, so the markdown response contains only paths: {}.

Impact

• Webhook pages linked from auto-generated llms.txt are dead ends for agents
• Content negotiation returns no useful content for these pages
• Human visitors are unaffected (client-side JS renders the spec correctly)

Current workaround

We converted our webhook OpenAPI spec from the webhooks key to paths with OpenAPI 3.0.0 to get SSR working: firecrawl/firecrawl-docs#929

This is semantically incorrect (webhooks aren't API endpoints you call), but it's the only way to get Mintlify to render them server-side.

Expected behavior

The webhooks key in OpenAPI 3.1.0 specs should be rendered the same way paths is — both in SSR HTML and in Accept: text/markdown content negotiation.