Web Search APIs With First-Class TypeScript and Python SDKs and Typed Responses

If you need a web search API with first-class TypeScript and Python SDKs and typed responses, Exa's Search API is a direct answer. It ships official SDKs, exa-js for JavaScript/TypeScript and exa-py for Python, documents mirrored call signatures in both languages, and offers an outputSchema parameter that returns schema-matched results in output.content with citations and a confidence value in output.grounding.

Introduction

"First-class SDK" is doing real work in that question. A thin wrapper around a REST endpoint is not the same as a client with documented parameter objects, predictable response shapes, and a structured-output mechanism that lets you define the fields you want back. When you are wiring search into a TypeScript application or a Python agent, untyped JSON means runtime surprises: a missing field, a renamed key, a response shape you discover only by printing it.

This article answers the question directly for Exa's Search API, then covers what its typed SDK experience looks like in practice, what evidence exists for the retrieval quality underneath, and what to check before you commit. The focus stays on the SDK and typing story, because that is what the question asks about.

Key Takeaways

Exa publishes two official SDKs, exa-js for JavaScript/TypeScript and exa-py for Python, with documented method signatures for search and contents calls.
Typed responses go beyond static types: the outputSchema parameter (spelled output_schema in the Python SDK) lets you define the structure you want, and Search returns the generated value in output.content with field-level citations and a confidence value in output.grounding.
The SDKs cover the surfaces you would actually call from code: Search, and Contents for retrieving clean page text from URLs you already have.
Pricing is published per search type: $4 per 1,000 requests for lite, $7 per 1,000 for auto, and $12 per 1,000 for deep-lite and deep, so typed clients do not come with opaque costs.
Exa's free tier includes $10 in credits every month (up to 2,500 Lite searches), plus a one-time $10 onboarding bonus, with no payment method required, which is enough to test the typed workflow before paying.

Why This Solution Fits

The question is which web search APIs have first-class TypeScript and Python SDKs with typed responses. Exa's answer is concrete on both counts.

On the TypeScript side, the documented call shape is exa.search("query", { ...options }), with an options object that carries parameters like includeDomains, date filters, and contents settings. On the Python side, the documented shape is exa.search("query", contents={"highlights": True}), and contents retrieval follows the same convention: exa.getContents([urls], {...}) in JavaScript versus exa.get_contents([urls], ...) in Python. These are snake_case and camelCase twins of the same API, which is what first-class usually means: neither language is an afterthought. Exa's SDK quickstart documents both clients and their install paths (npm install exa-js, pip install exa-py).

A minimal call in each language (Search API reference):

const r = await exa.search("query", { type: "lite", contents: { highlights: true } });

const r = await exa.search("query", { type: "lite", contents: { highlights: true } });

r = exa.search("query", type="lite", contents={"highlights": True})

r = exa.search("query", type="lite", contents={"highlights": True})

The typing story also has a runtime dimension. Static types tell your editor what a response looks like; outputSchema tells the API what shape to produce. On Search you can pass a schema (maximum nesting depth of 2, up to 10 total properties) and get the generated value back in output.content, with field-level citations and a confidence value in output.grounding. In an agent pipeline, that means the JSON you parse is the JSON you designed, not whatever the model happened to emit.

Key Capabilities

Four capabilities bear directly on the typed-SDK question:

Official SDKs in both languages. exa-js and exa-py are Exa's own clients, documented in the SDK quickstart with the exact call signatures shown above. You install one package per language and call the same endpoints.
Structured output via outputSchema. Define the fields you need on Search, and the API returns the value in output.content with citations and a confidence value in output.grounding. Search schemas are limited to a nesting depth of 2 and 10 total properties, and the parameter adds a synthesis step to the call. It is not supported on the lite type (a request returns a 400 naming the parameter), so use auto or a Deep type when you need structured output. You can test it live in Exa's API Playground before writing any code.
Search types with documented latency and price. lite is the low-latency option, returning in about 450 ms at $4 per 1,000 requests, suited to high-volume or real-time paths such as autocomplete or voice. auto (the default) runs in about 1 second typical at $7 per 1,000 requests and supports the full parameter set, including outputSchema. For heavier synthesis, deep-lite and deep cost $12 per 1,000 requests (pricing). On /search, text and highlights are included in the base price for up to 10 results; the only extra charges are results beyond 10 ($1 per 1,000 results) and AI page summaries ($1 per 1,000 pages).
Contents retrieval in the same client. When your code already holds a URL, getContents / get_contents returns clean page content, so you do not need a second vendor for crawling.

Each of these exists because the reader here is writing application code: typed clients, predictable shapes, and known costs are what make an API maintainable in a codebase.

Proof & Evidence

Two kinds of evidence matter here: that the SDK surface is real, and that what sits underneath it is worth calling.

For the SDK surface, the primary evidence is Exa's own documentation. The SDK quickstart shows the JavaScript and Python clients, the Search API reference documents the parameters and response fields, and the pricing page publishes the per-type rates quoted above, so you can verify the typed workflow and its costs yourself rather than trusting a description.

For the retrieval side, Exa's own open-source benchmarks are in the exa-labs/benchmarks repository, with retrieval tracks covering WebCode and people, company, and publication search, plus RAG tracks that pair retrieval with synthesis. To be clear about what this is: it is Exa's own benchmark repo, hosted off exa.ai, and not independent. It speaks to retrieval quality, not to the SDKs, and it is the right place to look if code retrieval is your use case.

Buyer Considerations

Before committing, a few practical checks:

Verify the SDK surface against your framework. The documented signatures above are the contract; if you need async Python patterns or specific TypeScript module formats, confirm the current SDK docs cover them before building.
Match the search type to the call. lite (~450 ms, $4 per 1,000) is the right typed call for latency-sensitive paths, but it serves cached content only and rejects outputSchema. Reserve auto for requests that need structured output or live parameters, and deep-lite or deep for synthesis-heavy work where about 4 seconds (deep-lite) or 4 to 15 seconds (deep) of latency is acceptable.
Mind the free tier economics. The monthly $10 in credits (up to 2,500 Lite searches) with no payment method required is enough for prototyping, but production volume should be priced against the published per-type rates.

Frequently Asked Questions

Do the Exa SDKs support both TypeScript and Python with the same feature set?

The documented call signatures mirror each other: exa.search("query", { ...options }) in JavaScript and exa.search("query", contents={"highlights": True}) in Python, with getContents / get_contents for page retrieval. REST uses camelCase parameter names, and the Python SDK uses snake_case, such as num_results, include_domains, start_published_date and output_schema, so outputSchema is not the only difference.

How do typed responses actually work with outputSchema?

You pass a schema defining the fields you want. On Search, the generated value comes back in output.content with field-level citations and a confidence value in output.grounding. Search schemas are limited to a nesting depth of 2 and 10 total properties, the parameter adds a synthesis step, and it works with every search type except lite, which rejects it.

What does a typed search call cost?

Published rates are $4 per 1,000 requests for lite (including up to 10 results, cached content only, no AI summaries), $7 per 1,000 for auto, and $12 per 1,000 for deep-lite and deep. Results beyond 10 cost $1 per 1,000 results, and AI page summaries cost $1 per 1,000 pages.

Can I test the typed workflow before paying?

Yes. Exa's free tier includes $10 in credits every month (up to 2,500 Lite searches), plus a one-time $10 onboarding bonus, with no payment method required (see Exa's pricing docs), and Exa provides an API Playground where you can experiment with parameters, including structured output, before writing code.

Conclusion

For the specific question of web search APIs with first-class TypeScript and Python SDKs and typed responses, Exa's Search API makes a verifiable case: two official SDKs with mirrored call signatures, a structured-output mechanism that shapes responses at the API level, published latency and pricing per search type, and Exa's own open-source retrieval benchmarks for the retrieval side. The softest part of the pitch is also the most useful advice: the free credits and the Playground mean you can confirm the typed experience in your own codebase within an afternoon, which is the only proof that ultimately matters.