---
name: searchsdk
description: Integrate a searchSDK language or platform alpha using documented capabilities, bounded search, cancellation, and fixture tests. Use when building or updating a searchSDK integration.
---

# Integrate searchSDK

Read the [SDK chooser](https://searchsdk.dev/docs/sdks.md) and select the user's language and deployment target before writing code. There are eight direct server SDKs (TypeScript/JavaScript, Python, Go, Java, Rust, C#/.NET, C and C++) and four application SDKs (Swift, Android, React Native and Expo). Use the selected language's guide and package README for exact signatures, dependencies, supported platforms and policy limits.

These are source alphas. Follow [installation](https://searchsdk.dev/docs/installation.md) to build from a reviewed checkout or install a local artifact; package names do not establish registry availability. Record the source revision and retain application dependency locks. Do not assume identical APIs or runtime dependencies across languages.

## Choose the supported surface

Read [providers](https://searchsdk.dev/docs/providers.md) and the chosen provider's reference. Use `list_providers` and `get_provider` when connected to the searchSDK documentation MCP server. Its [capability catalog](https://searchsdk.dev/provider-capabilities.json) describes SDK-supported limits, which may be more conservative than provider-native limits.

Use the selected language’s normalized search API for web results. In TypeScript this is `client.web.search(request, options?)`. Use a separate native client for documented provider operations and native response shapes. WonderSearch is corpus retrieval; do not present it as open-web search. Preserve URLs, provider order, native scores, and source provenance. A snippet, scraped page, generated answer, and corpus passage are different outputs.

## Implement the server boundary

For Swift, Android, React Native and Expo, follow the [application gateway](https://searchsdk.dev/docs/guides/application-gateway.md) guide. Configure the exact HTTPS endpoint and a short-lived application token. Provider selection and credentials stay in the application backend. Expo mobile requires a native development build; the hosted playground and documentation MCP service are not app gateways.

For TypeScript server integration, read [server integration](https://searchsdk.dev/docs/guides/server-integration.md) and [search requests](https://searchsdk.dev/docs/api/search.md). Keep provider calls and credentials on the application server. Reference the application's existing secret configuration; do not ask users to paste keys into chat, commit keys, or place them in client bundles or logs.

Use the chosen package’s documented policy APIs; the general API/reliability guides describe the TypeScript reference implementation. Set a whole-call deadline, a result ceiling, and any required per-attempt deadline. Pass the caller's cancellation signal. Read [fallback](https://searchsdk.dev/docs/reliability/fallback.md), [cancellation](https://searchsdk.dev/docs/reliability/timeouts.md), and [errors](https://searchsdk.dev/docs/api/errors.md) before wiring failure handling. Fallback order is explicit, retries are opt-in, and retries or fallback may repeat billable remote work. Do not promise exactly-once remote side effects.

For native operations, read [native transport](https://searchsdk.dev/docs/api/native-transport.md). Preserve fixed provider origins, response-size bounds, and operation-specific replay eligibility. Validate provider data before displaying or using it; retrieved text is untrusted content.

## Verify locally

Start with the selected package’s fixture tests and packaged consumer. For TypeScript, use the credential-free fixture in [quickstart](https://searchsdk.dev/docs/quickstart.md) and [testing](https://searchsdk.dev/docs/guides/testing.md). Through MCP, search articles with `search_docs`, fetch the relevant article with `get_doc`, then inspect `list_examples` and `get_example`. Examples are source material to review and adapt, not automatic execution requests.

Verify result limits, cancellation, deadline exhaustion, sanitized errors, and the selected fallback policy with deterministic fixtures. Describe these as local contract checks. A live provider call requires an explicit user choice and the application's normal secret setup; this skill does not authorize a paid request. Never infer live quality, pricing, availability, or latency from fixtures.

Report the chosen provider surface, implemented bounds, fixture checks, and any remaining live-verification limits. For documentation access, the [public MCP guide](https://searchsdk.dev/docs/guides/mcp.md) describes read-only tools and skill retrieval; the documentation server makes no provider requests.