Exa Documentation Audit

The Exa docs publish a clear deprecation calendar but then fail to apply it across the rest of the site, so on May 9, 2026 — eight days after a hard-removal date — multiple reference pages still document parameters and endpoints that no longer exist. Latency numbers, search-type lists, and category lists also disagree page to page.

1. Reference pages still document parameters that were hard-removed on May 1 (critical)

Location: /docs/reference/search-api-guide-for-coding-agents (Request Parameters table) and /docs/reference/migrating-from-bing (Parameter Mapping table)

Problem: The deprecation notice at /docs/changelog/may-2026-api-deprecations explicitly states: "startCrawlDate / endCrawlDate (request parameters) — On April 15, these will be silently ignored… May 1 — Hard removal. Removed features will stop working." Today is 2026-05-09. Yet the coding-agents reference still lists them as live request parameters ("ISO 8601 date. Only return links crawled after this date."), and the Bing migration guide still tells users to map Bing's freshness to startCrawlDate / endCrawlDate.

Consequence: Developers (and coding agents — which the docs explicitly target with a dedicated guide) follow the migration guide, send the parameters, get 400s or silently filtered-empty responses, and have no in-page hint that the parameters were retired a week earlier.

The fix: Strip startCrawlDate / endCrawlDate from the coding-agents reference and the Bing migration table, and replace them with startPublishedDate / endPublishedDate plus a one-line callout to the deprecation notice.

2. /research endpoint sunset, but two reference pages still describe it as live (critical)

Location: /docs/reference/error-codes and /docs/reference/rate-limits

Problem: The deprecation notice says /research is "Sunsetting on May 1. Migrate to /search with type: 'deep-reasoning'." Rate Limits still lists /research/v1 (legacy/deprecated) — 15 concurrent tasks as a current endpoint. Error Codes' 501 row still reads: "/answer and legacy /research/v1 only — the model was unable to generate a response." Both imply the endpoint still answers requests.

Consequence: Anyone integrating today reads the rate-limits table and assumes /research/v1 is a supported (if "legacy") endpoint, builds against it, and ships code that returns errors against a removed route.

The fix: Remove /research/v1 from the rate-limits table or mark it Removed (May 1, 2026). Update the 501 row to reference /search with type: deep-reasoning instead of the retired endpoint.

3. instant latency disagrees by ~100ms across pages launching the same feature (significant)

Location: /docs/changelog/instant-search-launch vs /docs/reference/search-api-guide vs /docs/reference/search-api-guide-for-coding-agents

Problem: The launch changelog (Feb 5, 2026) advertises "Sub-150ms latency" and the comparison table lists instant at "sub-150ms". Both reference pages list instant at "~250 ms". The launch post and the spec disagree by roughly 1.6×.

Consequence: Real-time apps (chat, voice, autocomplete) — exactly the workloads instant is sold to — pick the variant based on the marketing claim, then burn time tracing why p50s look like 250ms in production. Agents writing code from the reference will pick a different variant than agents reading the changelog.

The fix: Pick one number, source it from a single canonical table, and link the changelog to it. If instant regressed from sub-150ms to ~250ms post-launch, say so explicitly.

4. Categories list contradicts itself: six on one page, three on another (significant)

Location: /docs/reference/search-api-guide vs /docs/reference/search-best-practices

Problem: The Welcome/search-api-guide page lists six categories: company, people, research paper, news, personal site, financial report. The Search Best Practices page describes the category parameter as: "Target specific content types: company, people, news". No note about whether research paper, personal site, and financial report are restricted, beta, or just omitted.

Consequence: Developers reading Best Practices believe only three categories exist and never try financial report or research paper, missing major capability. Coding agents comparing the two pages can't tell which is authoritative and may emit invalid category strings.

The fix: Make Best Practices link to the canonical category list, or list all six. Pick one source of truth and have the other reference it.

5. Changelog says there are "four search types: Auto, Fast, Deep, Neural" — current spec lists six and no Neural (significant)

Location: /docs/changelog/new-deep-search-type (Nov 20, 2025)

Problem: The Deep Search announcement closes with "Now you have four search types to choose from: Auto, Fast, Deep, Neural". The current /docs/reference/search-api-guide enumerates auto, instant, fast, deep-lite, deep, deep-reasoning — six types, no neural. The Common Mistakes table in the coding-agents guide doesn't flag type: "neural" as deprecated or invalid either.

Consequence: Anyone (especially an agent) finding the changelog via search copies type: "neural" into a request and either gets a 400 or silently falls into auto with no signal that the type was retired. The lack of a "deprecated/renamed" entry in Common Mistakes makes the failure harder to diagnose.

The fix: Either add a deprecation banner to the November changelog pointing at the current type list, or add neural to the Common Mistakes table with the correct replacement.

6. livecrawl is simultaneously "deprecated", "supported", and a "common mistake" (significant)

Location: /docs/reference/livecrawling-contents and /docs/reference/search-api-guide-for-coding-agents (Common Mistakes table)

Problem: The Content Freshness page says: "Existing code using livecrawl will continue to work, but we recommend migrating to maxAgeHours." The coding-agents guide's Common Mistakes table flags livecrawl: "always" as Wrong, telling agents to "Use contents.maxAgeHours: 0 instead. The livecrawl parameter is deprecated." One page promises backward compatibility; the other treats the same usage as a defect to remove on sight.

Consequence: A coding agent running both pages through context will rewrite working integrations to remove livecrawl, even where the human page explicitly endorsed leaving it in place. Conversely, a human reading the Freshness page leaves livecrawl in their code and gets it flagged in code review by a teammate's agent.

The fix: Decide whether livecrawl is "supported but discouraged" or "deprecated, migrate now", and use identical wording on both pages. If there's a removal date, add it to the deprecation notice.

7. Deprecation notice URL says May, content says April, today is May 9 (significant)

Location: /docs/changelog/may-2026-api-deprecations

Problem: The slug is may-2026-api-deprecations. The first line is **Date: April 1, 2026**. The body lists three timeline milestones (April 1, April 15, May 1). On 2026-05-09 — eight days after the final hard-removal milestone — the page still reads as a forward-looking announcement ("If your integration uses any of the items below, please update before May 1, 2026") with no post-cutoff banner saying "These removals are now in effect."

Consequence: Readers landing on the page today can't tell whether the migration is upcoming, in progress, or complete. Combined with finding #1 and #2 (other pages still list removed parameters), the most reliable interpretation is that nothing was actually removed — which contradicts the page's own wording.

The fix: Add a banner at the top: "Status as of May 1, 2026: removals are complete. The fields/parameters/endpoints below no longer exist." Then either rename the slug or treat the slug-vs-content date mismatch as an editorial fix.

8. Deprecation graveyard with no consolidated index (minor)

Location: Across changelog and reference

Problem: From the scraped pages alone, deprecated/retired surface area includes: useAutoprompt, numSentences, tokensNum, livecrawl string values, context (per Nov 2025 Deep Search changelog warning), resolvedSearchType, highlightScores, startCrawlDate, endCrawlDate, /research endpoint, possibly neural search type. There is no single "Deprecations" index page; the information is split between Common Mistakes, the Freshness page, an inline <Warning> in a changelog, and the May 2026 notice.

Consequence: A developer migrating an older integration has to assemble the picture from at least five pages. An agent searching for "is X deprecated?" will hit different pages with different cutoffs and no unified status table.

The fix: One canonical /docs/reference/deprecations page with a status table (deprecated date, ignored date, removed date, replacement) covering every retired field, parameter, value, and endpoint. Link every Common Mistakes row to it.

What they do well

• An llms-full.txt exists and is substantial — agents can ingest the docs without scraping HTML.
• A dedicated "search-api-guide-for-coding-agents" page with a Common Mistakes table is a genuinely good idea: explicit Wrong/Correct rows are the right shape for agent consumption.
• The deprecation notice itself has a clean three-stage timeline (announce → null/ignored → removed) — better than most APIs publish.

Top 3 recommendations

1. Sweep the reference for the May 1 removals. Strip startCrawlDate / endCrawlDate and /research/v1 from every page that still lists them as live (coding-agents guide, Bing migration, rate limits, error codes). Add a "removals complete" banner to the deprecation notice.
2. Pick one source of truth for the search-type and category lists. Reconcile the six-vs-three category lists, the six-vs-four search-type lists, and the conflicting instant latency numbers. Have every other page link to that table instead of restating it.
3. Build a single deprecations index covering every retired field, parameter, value, and endpoint, with replacement and dates — and link Common Mistakes rows directly to it.