# Integrate on a server

Keep credentials and query policy behind your application's server boundary.

Canonical: https://searchsdk.dev/docs/guides/server-integration
Markdown: https://searchsdk.dev/docs/guides/server-integration.md

<a id="request-boundary"></a>

## Put policy at your request boundary

> **TypeScript reference**
> The API names, code and policy behavior in this article describe the TypeScript SDK. See [your language guide](https://searchsdk.dev/docs/sdks) for its supported surface and limits.

- 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.

<a id="reuse-client"></a>

## 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.

**search-service.ts · server**

```typescript
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);
```

<a id="batch-queries"></a>

## 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](https://searchsdk.dev/docs/api/search-batch)

<a id="operational-controls"></a>

## 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](https://searchsdk.dev/docs/reliability/retries)
- [Caching and request sharing](https://searchsdk.dev/docs/reliability/caching)
- [Credentials and untrusted data](https://searchsdk.dev/docs/reliability/security)