For one API call, a small fetch or requests snippet looks perfectly reasonable.
Once Search1API becomes part of an application, the repeated work appears quickly: maintaining request and response types for every endpoint, handling errors consistently, setting timeouts, deciding which failures are safe to retry, and writing polling logic for asynchronous jobs such as DeepCrawl.
Today we are releasing the official Search1API SDKs for TypeScript and Python. They are more than thin wrappers around HTTP requests. They turn that repetitive, failure-prone plumbing into language-native clients.
TypeScript: from generated types to runtime requests
Install the TypeScript client:
npm install @search1api/client import { Search1API } from '@search1api/client';
const client = new Search1API({
apiKey: process.env.SEARCH1API_API_KEY,
});
const response = await client.search('latest AI agent frameworks', {
maxResults: 10,
crawlResults: 3,
});
for (const result of response.results) {
console.log(result.title, result.link);
} The TypeScript SDK provides typed requests, responses, and errors. It also exports the lower-level wire types generated from Search1API's public OpenAPI contract. The package supports Node.js 18+ and other JavaScript runtimes with a standards-compatible fetch implementation.
Source: superagents-lab/search1api-js
Python: synchronous and asynchronous clients
Install the Python client:
pip install search1api The synchronous client fits scripts, job queues, and traditional web applications:
from search1api import Search1API
client = Search1API() # reads SEARCH1API_API_KEY
response = client.search(
"latest AI agent frameworks",
max_results=10,
crawl_results=3,
) Asynchronous applications can use AsyncSearch1API:
from search1api import AsyncSearch1API
async with AsyncSearch1API() as client:
response = await client.search("latest AI agent frameworks") Both clients cover the same public APIs and use the same approach to errors, retries, and DeepCrawl.
Source: superagents-lab/search1api-python
DeepCrawl without hand-written polling
DeepCrawl is an asynchronous job. When calling the REST API directly, an application needs to preserve the task ID, check its status, and wait for the result.
Both SDKs provide a convenience method that starts the task and waits for it to finish:
const result = await client.deepcrawl('https://example.com', { type: 'all' });
console.log(result.zipUrl); result = client.deepcrawl("https://example.com", type="all")
print(result["zipUrl"]) Applications that need to persist the task ID or control the polling schedule can still use the separate start, status, and wait methods.
Safer defaults for production code
Both SDKs use a 30-second request timeout by default and retry 429 and transient 5xx responses twice.
Authentication, payment or credit, and validation errors are never retried. Starting a DeepCrawl task is not retried automatically either, because repeating the request after a lost response could create and charge for a duplicate task.
The SDKs also expose separate error classes for authentication failures, insufficient credits or payment errors, invalid requests, missing resources, rate limits, and server failures. Applications can respond to the actual failure instead of rebuilding status-code checks around every call.
One public contract
The TypeScript and Python SDKs are checked against Search1API's public OpenAPI contract. When the API contract changes, the SDKs can verify that their clients still cover every public operation before a release.
The current clients support Search, News, Crawl, Sitemap, Trending, Extract, DeepCrawl, Usage, and Health, plus the batch operations exposed by the API.
Teams using another language can generate their own lower-level client from the public OpenAPI specification .
Should you use an SDK, the CLI, or MCP?
Calling Search1API from a TypeScript or Python application? Use an official SDK.
Giving a coding agent terminal access to search and web content? Use the Search1API CLI and Agent Skill.
Connecting an MCP-compatible AI client? Use Hosted MCP.
Working in another language or on a custom platform? Call the REST API directly or generate a client from the OpenAPI contract.
One boundary is worth making explicit: the TypeScript and Python SDKs currently use API keys. Browser-based OAuth 2.1 is currently available through the first-party CLI and OAuth-aware Hosted MCP clients. We do not want to blur the authentication capabilities of different integration paths.
Starting with v0.1.0
@search1api/client@0.1.0 and search1api@0.1.0 are now available from npm and PyPI. Both projects are maintained in public under the superagents-lab GitHub organization.
This is the starting point for the official SDKs. If you find a type, runtime, or API workflow that could be improved, open an issue in the relevant repository.
---
Build with Search1API in your application: Explore the official SDK documentation β
No comments yet