Integrate on a server

Put policy at your request boundary#

• Authenticate and authorize your application's caller before performing search.
• Validate application-specific query limits and usage policy before calling the SDK.
• Pass the incoming request's AbortSignal when your framework exposes one.
• Return only the fields the browser needs. Keep provider keys and internal account details on the server.

Configure once, call per request#

A normalized client holds provider configuration rather than user session state. Create it in server-owned code and pass a new search request and signal for each incoming request. Do not share a queued fixture provider across tests that assume isolated outcomes.

import { createSearch } from '@belweave/search-sdk';
import { context } from '@belweave/search-sdk/context';

const apiKey = process.env.CONTEXT_API_KEY;
if (!apiKey) throw new Error('CONTEXT_API_KEY is required');

const client = createSearch({
  provider: context({ apiKey }),
  timeoutMs: 10_000,
});

const response = await client.web.search({
  query: 'SQLite write concurrency',
  limit: 5,
});

for (const result of response.results) {
  console.log(result.title ?? result.url, result.url);
}
console.log(response.provider, response.attempts);

Run independent queries in a bounded batch#

Use web.searchBatch for multiple queries with an explicit worker limit and ordered per-item outcomes. Each query retains the same client policy; successful items survive a sibling failure.

• Batch query reference and fixture↗

Add application controls deliberately#

The normalized client supports opt-in retries, a local successful-result cache, identical in-flight request sharing, and bounded concurrency. Configure these deliberately because queries may contain sensitive material and retries can repeat billable work. Per-user quotas and telemetry remain application policy. Avoid logging full query bodies or transport headers by default.

• Retry policy↗
• Caching and request sharing↗
• Credentials and untrusted data↗