Exa

PASS consensus from 2 PASS, 1 PARTIAL.

The quickstart covers key creation, installation, and search, but it never shows how to print or iterate returned results. The Human Quickstart runs key, export EXA_API_KEY, pip install exa-py, and a working exa.search(...) call in one unbroken sequence on a single page, and the Python SDK Specification documents the returned Result fields (url, title, score, highlights) so the results can be inspected. Three-step path (API key → install → run) is documented in one page with a minimal working example; no ambiguity or cross-referencing required.

PARTIAL consensus from 3 PARTIAL.

The docs give credits, prices, and Enterprise differences, but rate-limits says 10 QPS while Starter pricing says 5 QPS. Free credits ($20 signup plus $10 monthly) and per-request pricing agree exactly between Pricing and Billing, but the Enterprise card implies a 25-result public ceiling while the Search API schema states "The maximum public limit is 100 results", and the Rate Limits table publishes QPS for only /search, /contents, and /answer with no figures for /agent, /monitors, /context, or /websets. Values per page are individually clear, but the rate-limits page and pricing page contradict each other on the default QPS (rate-limits says 10 universally; pricing shows Starter tier at 5). Enterprise differences are clearly listed as custom QPS, up to 1,000 results, and volume discounts.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The endpoint table gives QPS values, but the 429 guidance omits delay, multiplier, cap, jitter, and Retry-After handling. The 429 body names the numeric limit and the Error Codes table prescribes "Implement exponential backoff and reduce request rate", but no page documents a Retry-After header, gives backoff parameters or a retry code sample, or assigns an error tag to 429, and the exceeded limit cannot be identified from the docs for any endpoint outside the three in the Rate Limits table. All three recovery steps (identify endpoint limit from rate-limits page, reduce request rate, exponential backoff) are documented. The 429 error body lacks Retry-After header and concrete backoff parameters, but the guidance to implement exponential backoff is unambiguous.

PASS consensus from 2 PASS, 1 PARTIAL.

The receive-and-verify flow is complete, but both creation examples use two event names absent from the documented enum. The chain is complete end to end: Create a Webhook documents the 19-value EventType enum and that secret is "Only returned on Webhook creation", and Verifying Signatures gives the t=/v1= header format, a four-step procedure, runnable Python, JavaScript, and Java, timing-safe comparison, a 300-second replay window, and a raw-body troubleshooting section. Complete end-to-end process documented: create webhook with secret-only-once response, parse Exa-Signature header format t=<ts>,v1=<hex>, compute HMAC-SHA256 over timestamp.rawBody, use timing-safe comparison, check timestamp freshness. Python code example provided.

PASS consensus from 3 PASS.

The SDK page documents installation, environment-key initialization, and a minimum search matching the REST query and contents shape. The SDK minimum, exa.search(query, contents={"highlights": True}), is byte-for-byte the same shape as the REST Minimal Working Example on the Search API Reference for coding agents, and both pages carry the same warning that text, highlights, and summary nest inside contents on /search. Python SDK examples in the SDK page and in the Search API coding-agent guide agree with each other and with the REST API guidance. The snake_case vs camelCase divergence is explicitly documented, leaving no room for guesswork.