# Find and compare SDKs.

Libraries for email, search, databases, and more. Compare providers, capabilities, and installation options.

[Browse SDKs](/sdks) · [Read the docs](/docs)

## Categories

- [Search](/sdks?category=search) (6 SDKs): Web search, extraction, and agent search integrations.
- [Databases](/sdks?category=database) (6 SDKs): Database clients, drivers, ORMs, and query builders.
- [Email](/sdks?category=email) (2 SDKs): Transactional email clients and adapters.
- [Social](/sdks?category=social) (1 SDKs): Direct and managed social platform integrations.
- [Domains](/sdks?category=domains) (2 SDKs): Customer hostnames, DNS, and domain verification.
- [Sandboxes](/sdks?category=sandbox) (2 SDKs): Isolated code execution and sandbox lifecycle tools.
- [Files](/sdks?category=files) (3 SDKs): Object storage, file operations, and upload workflows.
- [SMS](/sdks?category=sms) (2 SDKs): Transactional messaging clients and provider adapters.

## Code examples

[Quickstart](/docs/quickstart)

### Search — searchSDK

Unified SDK · TypeScript

[Build from source](/sdks/searchsdk#install-title)

**search.ts**

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

const search = createSearch({
  provider: context({
    apiKey: process.env.CONTEXT_API_KEY!,
  }),
  timeoutMs: 10_000,
});

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

Build the TypeScript package for Node 24+. Live searches use your provider account.

[Explore Search SDKs](/sdks/searchsdk)

### Database — dbSDK

Unified SDK · TypeScript

[Build from source](/sdks/dbsdk#install-title)

**query.ts**

```typescript
import { createDatabase } from 'dbsdk';
import { neon } from 'dbsdk/neon';

const db = createDatabase({
  adapter: neon({
    connectionString: process.env.DATABASE_URL!,
    transport: 'http',
  }),
});

try {
  const { rows } = await db.sql`select version()`;
  console.log(rows);
} finally {
  await db.close();
}
```

Build dbSDK from source and install the Neon driver peer. Requires a Neon database.

[Explore Database SDKs](/sdks/dbsdk)

### Email — Email SDK

Unified SDK · TypeScript

```shell
npm install @opencoredev/email-sdk
```

**send-email.ts**

```typescript
import { createEmailClient } from '@opencoredev/email-sdk';
import { resend } from '@opencoredev/email-sdk/resend';

const email = createEmailClient({
  adapters: [resend({
    apiKey: process.env.RESEND_API_KEY!,
  })],
  telemetry: false,
});

await email.send({
  from: 'hello@your-domain.com',
  to: 'delivered@resend.dev',
  subject: 'Hello',
  text: 'Your first message with Email SDK.',
});
```

OpenCore’s email SDK with the Resend adapter. Requires an API key and a verified sender domain.

[Explore Email SDKs](/sdks/email-sdk)

sdkSDK by Belweave

Source: https://sdk-sdk.com/

---

# SDK directory

Browse 24 independently curated SDKs. Search by name, provider, package, language, feature, or best-for use case; filter by category. Share filters with /sdks?q=your-query&category=category-id.

## Categories

- [Search](/sdks?category=search) (6 SDKs): Web search, extraction, and agent search integrations.
- [Databases](/sdks?category=database) (6 SDKs): Database clients, drivers, ORMs, and query builders.
- [Email](/sdks?category=email) (2 SDKs): Transactional email clients and adapters.
- [Social](/sdks?category=social) (1 SDKs): Direct and managed social platform integrations.
- [Domains](/sdks?category=domains) (2 SDKs): Customer hostnames, DNS, and domain verification.
- [Sandboxes](/sdks?category=sandbox) (2 SDKs): Isolated code execution and sandbox lifecycle tools.
- [Files](/sdks?category=files) (3 SDKs): Object storage, file operations, and upload workflows.
- [SMS](/sdks?category=sms) (2 SDKs): Transactional messaging clients and provider adapters.

## SDK approaches

- Unified SDK: a shared interface across supported providers. Integration coverage and behavior can differ by provider.
- Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider.
- Toolkit: building blocks for a workflow. Check its features and caveats for the scope of its provider integrations.

## Directory entries

- [searchSDK](/sdks/searchsdk) — Search across providers from twelve language and platform SDKs. Package: @belweave/search-sdk.
- [dbSDK](/sdks/dbsdk) — Create, manage, and query PostgreSQL databases through one typed SDK. Package: dbsdk.
- [Email SDK](/sdks/email-sdk) — One typed email API over multiple delivery providers. Package: @opencoredev/email-sdk.
- [Social SDK](/sdks/social-sdk) — Typed social integrations with direct and managed routes. Package: @opencoredev/social-sdk.
- [Domain SDK](/sdks/domain-sdk) — A shared lifecycle for customer domains on hosting platforms. Package: @opencoredev/domain-sdk.
- [Sandbox SDK](/sdks/sandbox-sdk) — A shared API for local and hosted code sandboxes. Package: @opencoredev/sandbox-sdk.
- [SMS SDK](/sdks/sms-sdk) — One transactional SMS API across six messaging providers. Package: @opencoredev/sms-sdk.
- [Resend Node.js SDK](/sdks/resend) — Resend's official client for its email API. Package: resend.
- [Cloudflare TypeScript SDK](/sdks/cloudflare) — Cloudflare's official API client, including DNS and zones. Package: cloudflare.
- [E2B Code Interpreter](/sdks/e2b-code-interpreter) — E2B's native SDK for stateful sandboxed code execution. Package: @e2b/code-interpreter.
- [Files SDK](/sdks/files-sdk) — A common file API across object and blob storage backends. Package: files-sdk.
- [AWS SDK for JavaScript — S3](/sdks/aws-s3) — AWS's official modular JavaScript client for Amazon S3. Package: @aws-sdk/client-s3.
- [UploadThing](/sdks/uploadthing) — Typed file upload routes and clients for web applications. Package: uploadthing.
- [Twilio Node.js SDK](/sdks/twilio) — Twilio's official server-side API helper library. Package: twilio.
- [Search SDK by Plust](/sdks/plust-search-sdk) — An independent adapter library for multiple web search APIs. Package: @plust/search-sdk.
- [Tavily JavaScript SDK](/sdks/tavily) — Tavily's official web search and extraction client. Package: @tavily/core.
- [Exa JavaScript SDK](/sdks/exa) — Exa's official client for AI-oriented web search. Package: exa-js.
- [Brave Search MCP Server](/sdks/brave-search-mcp) — Brave's official search integration for MCP clients. Package: @brave/brave-search-mcp-server.
- [Firecrawl Node SDK](/sdks/firecrawl) — Firecrawl's official web search, scrape, and crawl client. Package: firecrawl.
- [Prisma ORM](/sdks/prisma) — A typed data layer with contracts, queries, and migrations. Package: @prisma/orm-postgres.
- [Drizzle ORM](/sdks/drizzle) — A TypeScript ORM with SQL-like and relational query APIs. Package: drizzle-orm.
- [Supabase JavaScript Client](/sdks/supabase) — Supabase's official client for its backend services. Package: @supabase/supabase-js.
- [Neon Serverless Driver](/sdks/neon) — Neon's PostgreSQL driver over HTTP and WebSockets. Package: @neondatabase/serverless.
- [Kysely](/sdks/kysely) — A type-safe SQL query builder for TypeScript. Package: kysely.

## Compare SDKs

Select 2–3 SDKs in the directory to compare their approach, providers, features, and caveats. The comparison tray holds up to 3 selections. Clear or remove selections to change the comparison.

[Comparison guide](/sdks/compare)

[Editorial criteria](/docs/contributing)

Source: https://sdk-sdk.com/sdks

---

# Compare SDKs

Select 2–3 SDKs in the directory to compare their approach, providers, features, and caveats here. With no SDKs selected, choose SDKs from the directory. With one selected, choose at least one more.

Share a comparison using /sdks/compare?ids=slug-one,slug-two,slug-three. The page removes duplicate IDs, reports unknown entries, and displays the first three available selections. Add an SDK or change the selection from the directory.

## Compared fields

- Approach
- Category
- Best for
- Language
- Distribution notes
- License
- Package
- Install
- Listed providers
- Features
- Caveats
- Official links
- Sources and review date

## Understand the approaches

- Unified SDK: a shared interface across supported providers. Integration coverage and behavior can differ by provider.
- Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider.
- Toolkit: building blocks for a workflow. Check its features and caveats for the scope of its provider integrations.

Features and provider lists describe each entry’s documented scope, not guaranteed parity. Review provider-specific caveats, account requirements, availability, and primary sources before choosing.

[Choose SDKs](/sdks)

Source: https://sdk-sdk.com/sdks/compare

---

# About SDK SDK

SDK SDK brings the scattered world of software development kits into one considered directory. A place to understand the options, follow the source, and start building.

## Purpose

Choosing an SDK means more than finding a package name. You need to know who maintains it, which providers it supports, what it abstracts, and where that abstraction ends.

We’re building a starting point for that work: a curated catalog spanning email, social platforms, domains, sandboxes, files, SMS, search, and databases. Each entry points back to its official documentation and source.

SDK SDK is an independent project by Belweave. Listed projects belong to their respective maintainers. Inclusion is editorial and does not imply a partnership or endorsement.

## Editorial approach

We distinguish unified SDKs, provider clients, and developer toolkits. They solve different problems, and a shared category doesn’t make them interchangeable.

1. **Start with primary sources.** Official documentation, source repositories, and package metadata inform every listing.
2. **Make limitations visible.** Provider-specific behavior, account requirements, and important caveats belong beside the features.
3. **Teach the decision.** Our docs cover capabilities, testing, configuration, and fallback semantics so you can evaluate the next SDK yourself.
4. **Keep scope honest.** This is a curated starting collection, not an exhaustive inventory. Package APIs and provider support change; check upstream before shipping.

[Read the entry criteria](/docs/contributing)

## Our projects

sdk-sdk.com is the umbrella. Our search and database SDKs provide shared interfaces across supported providers. Their current availability is part of each listing, and their shared ownership is disclosed.

### searchSDK.dev

Open source · source alpha

Twelve language and platform SDKs, fourteen search adapters, and thirteen provider-native clients. Public MIT-licensed source, language guides, and a playground with live and key-free demo modes.

[Explore searchSDK](/sdks/searchsdk)

### dbSDK.com / database-sdk.dev

Source-only · v0.1

Provision and manage databases, run typed PostgreSQL queries, use Drizzle, and transfer data between supported providers. Public Apache-2.0 source and docs; install from a source build.

[Explore dbSDK](/sdks/dbsdk)

Source: https://sdk-sdk.com/about

---

# Introduction

A practical field guide to finding, choosing, and working with SDKs.

Better integrations start with better choices. Find the right SDK, understand its tradeoffs, and build a boundary your application can live with.

Get started · 4 min read

## What is SDK SDK?

SDK SDK is an independent, curated discovery hub for software development kits. We bring useful libraries, official documentation, and practical integration lessons into one place so you can spend less time comparing tabs and more time building.

> [!NOTE]
> **A directory and a field guide**
>
> There is no universal SDK SDK package to install. Choose a library from the directory and install it from its official source. The patterns in these docs are code you own in your application.

## Find your starting point

- [Make your first API call](/docs/quickstart) — A real Resend integration, from install to response.
- [Choose with confidence](/docs/choosing-an-sdk) — A short evaluation framework for your next dependency.
- [Explore SDKs](/sdks) — Browse the directory by the job you need to do.
- [Build a reliable boundary](/docs/capabilities) — Declare capabilities before adding abstractions.

## A small integration loop

1. **Start with a job.** Describe the outcome: send a receipt, retrieve a page, or save an order. List the constraints that would rule a provider out.
2. **Read the primary docs.** Check the supported runtime, authentication, response model, and limits for the exact operation you need.
3. **Try the native client.** Make one successful call before deciding what your own integration boundary should expose.
4. **Test the failure path.** Add deterministic fixtures, a deadline, and a clear policy for retries and sensitive data.

## Principles worth keeping

| Principle | In practice |
| --- | --- |
| Explicit capabilities | A provider supports a specific operation, with specific semantics. Make that visible. |
| Deterministic mocks | Test fixtures control IDs, time, errors, and ordering. A mock never quietly calls a live provider. |
| Honest data types | A search snippet is not a retrieved page. A retrieved page is not a generated answer. |
| Bounded recovery | A retry spends time and money. A fallback can send data to another company. |
| Native escape hatches | Keep access to useful provider-specific features instead of reducing every SDK to the same surface. |

## Using these docs

Official provider examples are identified and linked to their sources. Examples labeled **app-owned** are illustrative TypeScript patterns you can adapt; they are not exported by SDK SDK or guaranteed to match a provider's API. Always check the installed version's documentation before shipping.

Start small. A direct call to the official SDK is often enough. Add your own abstraction when it makes a real requirement—such as testing, provider selection, or observability—easier to express.

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.

Source: https://sdk-sdk.com/docs

---

# Quickstart

Go from a provider decision to your first real API call with Resend.

Make one useful integration work end to end. This guide sends a test email using Resend's official Node.js SDK.

Get started · 5 min read

## Before you start

You will need a server-side Node.js project and a Resend account. Create an API key and complete sender setup using the [official Resend Node.js guide](https://resend.com/docs/send-with-nodejs). Use a verified domain for your own sender address.

> [!TIP]
> **Keep the first call small**
>
> The example uses Resend's documented testing addresses. A successful API response confirms acceptance of the request; inspect delivery events separately when testing real recipients.

## 1. Install the official SDK

**Terminal · in your application**

```bash
npm install resend
```

Install the provider's package directly. SDK SDK is the guide that helps you choose it; it is not another dependency in the request path.

## 2. Configure your environment

**.env.local · Next.js**

```dotenv
# Replace locally. Do not commit this value.
RESEND_API_KEY=your_resend_api_key
```

Next.js loads `.env*` values into `process.env`. Keep this secret unprefixed: `NEXT_PUBLIC_` variables are bundled for the browser. See [Next.js environment variables](https://nextjs.org/docs/app/guides/environment-variables). For another runtime, use its documented environment loader.

## 3. Send a test email

Run this in server-side application code with the environment loaded. It adapts the [official Resend sending example](https://resend.com/docs/send-with-nodejs) and checks both a missing key and a failed response.

**send-test.ts · official Resend SDK**

```typescript
import { Resend } from 'resend';

const apiKey = process.env.RESEND_API_KEY;
if (!apiKey) throw new Error('Missing RESEND_API_KEY');

const resend = new Resend(apiKey);

export async function sendTestEmail() {
  const { data, error } = await resend.emails.send({
    from: 'SDK SDK <onboarding@resend.dev>',
    to: ['delivered@resend.dev'],
    subject: 'Your first integration',
    text: 'One small integration, working end to end.',
  });

  if (error) throw new Error(error.message);
  if (!data) throw new Error('No email result returned');
  return { id: data.id };
}

// Call from a trusted server workflow.
// await sendTestEmail();
```

> [!WARNING]
> **Server code only**
>
> Do not expose a public endpoint that sends arbitrary email without authentication, input validation, and abuse controls. Keep credentials and the provider client on the server.

## 4. Understand the result

Keep the returned identifier for tracing. The [Send Email reference](https://resend.com/docs/api-reference/emails/send-email) documents request fields and the response. Handle provider errors separately from transport exceptions, and avoid logging the message body or recipient list by default.

- Confirm which sender and recipient are allowed in your account.
- Make one intentional call; avoid invoking email sending during component rendering.
- If the call times out, investigate before sending again. A timeout does not prove the email was never accepted.

## Where to go next

- [Provider configuration](/docs/provider-configuration) — Validate configuration and keep environments separate.
- [Testing & mocks](/docs/testing) — Exercise the integration without sending real email.

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.

Source: https://sdk-sdk.com/docs/quickstart

---

# Choosing an SDK

Evaluate the runtime, API surface, maintenance, and tradeoffs that matter to your application.

Choose the smallest dependency that does the job well in your runtime. A popular package is a starting point for evaluation, not the conclusion.

Get started · 5 min read

## Define the job first

Write down the operation your application needs and the constraints it must respect. “Search” is broad. “Find five recent source URLs with snippets from an approved set of domains” gives you something concrete to evaluate.

- **Runtime:** browser, Node.js server, edge runtime, mobile, or a background worker?
- **Data:** what will leave your system, and where may it be processed?
- **Behavior:** streaming, pagination, transactions, cancellation, or idempotency?
- **Operations:** expected volume, response deadline, budget, and failure tolerance?

## Evaluate the library

| Look for | Questions to answer |
| --- | --- |
| Provenance | Is it maintained by the provider or the community? Is the repository linked from official docs? |
| Runtime fit | Does the documented runtime match your deployment? Are native modules or Node APIs required? |
| API coverage | Does it support your exact operation, including the options you cannot give up? |
| Maintenance | Are releases, migration notes, and issue responses consistent with your needs? |
| Failure model | How are HTTP errors, transport failures, timeouts, and partial results represented? |
| Operational fit | Can you set deadlines, inspect request IDs, and understand retry behavior? |

> [!NOTE]
> **Check the version you will install**
>
> Directory descriptions help with discovery. The installed package, its release notes, and its official versioned documentation determine the API you can use.

## Run a small integration spike

1. Install the official package in a throwaway branch or isolated example.
2. Make one happy-path call with realistic input.
3. Trigger one validation error and one controlled timeout.
4. Record the useful result, native error details, and any missing capabilities.
5. Run it in the actual target runtime before committing to the dependency.

For an email integration, the [Resend official Node.js repository](https://github.com/resend/resend-node) and [sending reference](https://resend.com/docs/api-reference/emails/send-email) are useful primary sources. Follow the same source trail for every provider you evaluate.

## Decide what to wrap

Start with the native client. Extract a narrow application boundary when your product has a stable operation to name. Keep provider-specific options close to the integration, and avoid designing a universal interface before you have a second real use case.

**App-owned boundary · illustrative**

```typescript
type ReceiptEmail = {
  orderId: string;
  recipient: string;
};

// Your product operation, not a universal email API.
export interface ReceiptSender {
  sendReceipt(input: ReceiptEmail): Promise<{
    messageId: string;
    provider: string;
  }>;
}
```

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.

Source: https://sdk-sdk.com/docs/choosing-an-sdk

---

# Provider configuration

Make credentials, environments, and provider selection explicit.

Configuration is part of the integration contract. Make the provider, credentials, and environment visible before the first network call.

Core concepts · 4 min read

## Validate at the boundary

Read environment variables in a server-only module. Validate the selected provider and required values before constructing a client. A missing credential should produce a useful configuration error, not silently select a different provider.

**App-owned configuration · illustrative**

```typescript
type EmailConfig = {
  provider: 'resend';
  apiKey: string;
  from: string;
};

export function readEmailConfig(
  env: Record<string, string | undefined>,
): EmailConfig {
  const apiKey = env.RESEND_API_KEY;
  const from = env.EMAIL_FROM;
  if (!apiKey || !from) {
    throw new Error('Email requires RESEND_API_KEY and EMAIL_FROM');
  }
  return { provider: 'resend', apiKey, from };
}
```

## Keep secrets server-side

In Next.js, variables without the `NEXT_PUBLIC_` prefix remain available to the server environment; public-prefixed values are inlined into browser bundles. Follow the [official environment variable guide](https://nextjs.org/docs/app/guides/environment-variables), and keep privileged clients out of client components.

> [!WARNING]
> **Public configuration is a deliberate choice**
>
> Some SDKs support browser clients with public keys and a separate authorization model. A public key is not a substitute for access control. Follow that provider's documented security model.

For example, [Supabase client initialization](https://supabase.com/docs/reference/javascript/initializing) and [row-level security](https://supabase.com/docs/guides/database/postgres/row-level-security) should be considered together when configuring a browser client.

## Separate environments

| Environment | Recommended configuration |
| --- | --- |
| Local development | Explicit mock mode or a dedicated development account. Never infer mock mode from a missing secret. |
| Preview | Separate credentials, safe recipients, and a strict spending limit where supported. |
| Production | Scoped credentials, rotation procedures, and an explicitly configured provider. |

Keep a committed `.env.example` with variable names and placeholder values. Store real values in your local environment or deployment secret store, and avoid copying production credentials into preview environments.

## Make operations observable

Record the operation name, provider, duration, result category, and request identifier when available. Make payload logging opt-in and redacted. A configuration error, a rejected request, and an exhausted retry budget should be distinguishable in your telemetry.

- Keep credentials out of logs, errors, URLs, and screenshots.
- Assign timeouts and retry policy in one intentional layer.
- Document who owns credential rotation and provider account access.

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.

Source: https://sdk-sdk.com/docs/provider-configuration

---

# Capabilities

Model what a provider actually supports without hiding meaningful differences.

An integration is useful when it tells the truth about what it can do. Declare capabilities and preserve the differences that affect your product.

Core concepts · 5 min read

## Model operations explicitly

A single `execute()` function cannot tell a caller whether a provider returns snippets, full documents, or a generated answer. Name operations according to the output and guarantees they provide, then validate requirements before making a request.

**App-owned capability model · illustrative**

```typescript
type SearchCapability =
  | 'web.search'
  | 'web.extract'
  | 'web.answer';

interface ProviderDescriptor {
  id: string;
  capabilities: ReadonlySet<SearchCapability>;
}

function requireCapability(
  provider: ProviderDescriptor,
  capability: SearchCapability,
) {
  if (!provider.capabilities.has(capability)) {
    throw new Error(
      provider.id + ' does not support ' + capability,
    );
  }
}
```

## Capabilities have semantics

| Capability | Document the details |
| --- | --- |
| Streaming | What is emitted, how errors arrive, and whether cancellation stops upstream work. |
| Pagination | Cursor or offset, ordering guarantees, and whether the result set can change between pages. |
| Idempotency | Supported operations, key scope, retention window, and conflicts. |
| Extraction | Supported formats, partial failures, blocked pages, and content freshness. |
| Transactions | Atomicity, isolation, connection requirements, and supported database engines. |

For a concrete example, [Resend's idempotency documentation](https://resend.com/docs/dashboard/emails/idempotency-keys) defines supported operations and a 24-hour key window. Record those limits rather than treating idempotency as an unlimited boolean promise.

## Fail honestly

> [!NOTE]
> **Unsupported is a useful result**
>
> Do not return an empty array when an operation is unsupported. An empty search result means a search ran and found nothing; unsupported means the search could not run.

Validate required capabilities during provider selection. Distinguish unsupported behavior from invalid input, permission errors, transient service failures, and partial success. Preserve enough native detail for a maintainer to investigate.

## Keep native escape hatches

Your shared boundary should cover common application needs. When a feature only exists in one provider, use that provider's native SDK deliberately. Keep the code clearly named and local to the integration so the dependency is easy to see.

**Native SDK option · official Resend API**

```typescript
// Keep provider-specific semantics visible.
await resend.emails.send(
  {
    from: verifiedSender,
    to: [recipient],
    subject: 'Order confirmed',
    text: 'Thank you for your order.',
  },
  { idempotencyKey: 'order-confirmation/' + orderId },
);
```

This fragment assumes an initialized Resend client and validated application values. The second argument follows the [official idempotency key example](https://resend.com/docs/dashboard/emails/idempotency-keys); reuse the key only for the same logical request.

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.

Source: https://sdk-sdk.com/docs/capabilities

---

# Testing & mocks

Build deterministic tests at your application's integration boundary.

Keep most integration tests local, predictable, and free of side effects. Use a smaller set of explicit live checks to verify the real provider contract.

Core concepts · 5 min read

## Test your application boundary

Inject the operation your product needs instead of constructing a live SDK client inside business logic. A deterministic fake lets you verify the inputs and outcomes that matter without imitating every internal detail of a provider library.

**email.ts · illustrative app-owned workflow and fake**

```typescript
type EmailInput = { to: string; subject: string };
type EmailSender = {
  send(input: EmailInput): Promise<{ id: string }>;
};

export async function sendWelcome(
  sender: EmailSender,
  recipient: string,
) {
  return sender.send({
    to: recipient.trim(),
    subject: 'Welcome',
  });
}

export function createFakeEmailSender() {
  const calls: EmailInput[] = [];
  const sender: EmailSender = {
    async send(input) {
      calls.push({ ...input });
      return { id: 'email_fixture_001' };
    },
  };
  return { sender, calls };
}
```

## Make fixtures deterministic

Use fixed identifiers and explicit error fixtures. Inject clocks, ID generators, and random-number sources when the behavior depends on them. Create a fresh fake for each test so execution order cannot change the result.

**Workflow test · node:test + app-owned fake**

```typescript
import test from 'node:test';
import assert from 'node:assert/strict';
import { createFakeEmailSender, sendWelcome } from './email';

test('welcome sends to the normalized recipient', async () => {
  const { sender, calls } = createFakeEmailSender();
  const result = await sendWelcome(
    sender,
    '  reader@example.com  ',
  );

  assert.equal(result.id, 'email_fixture_001');
  assert.deepEqual(calls, [{
    to: 'reader@example.com',
    subject: 'Welcome',
  }]);
});
```

The example uses the built-in [Node.js test runner](https://nodejs.org/api/test.html). Run TypeScript through your project's configured test toolchain. The fake records what the welcome workflow actually sends, so the test checks recipient normalization and the product's chosen subject.

## Cover the difficult paths

| Fixture | Behavior to verify |
| --- | --- |
| Invalid input | Validation fails before a provider request is made. |
| Unsupported capability | No empty-success response or accidental fallback. |
| Rate limit | The retry policy respects its deadline and attempt budget. |
| Timeout after submission | A side effect is not blindly repeated. |
| Partial result | Failed items remain visible alongside successful items. |
| Privacy restriction | No data is sent to an unapproved fallback provider. |

## Separate live contract checks

> [!NOTE]
> **A fake is not proof of provider compatibility**
>
> Local tests prove your application behavior. A live contract check verifies that your adapter still agrees with the installed SDK and real service. Keep those checks explicit and safe to run.

Use dedicated credentials and test data, set a spending limit, and clean up created records. Require an explicit opt-in for tests that contact a provider. Never let a missing fixture or environment variable quietly turn a local test into a live request.

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.

Source: https://sdk-sdk.com/docs/testing

---

# Retries & fallbacks

Design recovery around deadlines, duplicate effects, cost, and privacy.

Recovery is a product decision. Every extra attempt consumes a deadline, may incur a charge, and can create another side effect.

Core concepts · 5 min read

## Retry or fallback?

A retry asks the same provider to perform the same operation again. A fallback routes the operation to another implementation. These decisions have different correctness, privacy, and billing consequences; configure them separately.

| Situation | A reasonable starting policy |
| --- | --- |
| Invalid credentials or input | Stop and surface a configuration or validation error. |
| Temporary rate limit | Consider a bounded retry, following documented retry guidance. |
| Read timeout | Retry only within the deadline and cost budget. |
| Write timeout | Treat completion as unknown; reconcile or use documented idempotency. |
| Provider outage | Fallback only when capabilities and data-processing policies match. |

## Set a recovery budget

**App-owned policy data · illustrative**

```typescript
type RecoveryPolicy = {
  maxAttempts: number; // Includes the initial request
  deadlineMs: number;  // Covers the whole operation
  maxEstimatedCostUsd: number;
  approvedProviderIds: readonly string[];
};

const searchPolicy: RecoveryPolicy = {
  maxAttempts: 2,
  deadlineMs: 4_000,
  maxEstimatedCostUsd: 0.01, // Application budget, not provider pricing
  approvedProviderIds: ['primary-search'],
};
```

Before every attempt, check remaining time, attempts, estimated cost, and approval for the provider. Use bounded backoff with jitter where appropriate. Understand the native SDK's retry behavior so your application loop does not multiply retries underneath it.

> [!NOTE]
> **Budgets need enforcement**
>
> The object above only describes policy. Your request layer must enforce it, account for SDK-internal attempts, and handle missing or uncertain cost estimates conservatively.

## Protect side effects

A timed-out request may have completed upstream. For email, payments, or writes, avoid inferring failure from a lost response. Use the provider's documented idempotency mechanism when available and persist the logical operation identifier before retrying.

[Resend's idempotency guide](https://resend.com/docs/dashboard/emails/idempotency-keys) documents its key behavior. A key at one provider does not deduplicate work at another provider; cross-provider delivery needs an application-owned reconciliation strategy.

## Respect data boundaries

A secondary provider is another destination for your data. Approve it before an outage, including retention, region, contractual constraints, and the exact payload it may receive. Redacting logs does not prevent sensitive input from being sent upstream.

- Fallback must satisfy the original capability requirements.
- Return provider provenance when it affects interpretation of results.
- Record each attempt without copying secrets or full payloads into telemetry.
- If recovery is exhausted, return a clear failure rather than a fabricated success.

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.

Source: https://sdk-sdk.com/docs/fallbacks

---

# Search

Keep search snippets, extracted page content, and generated answers distinct.

Search is a pipeline of distinct operations. Finding a useful URL, retrieving its contents, and generating an answer require different contracts.

Guides · 5 min read

## Three different outputs

| Output | What it represents |
| --- | --- |
| Search snippet | A short excerpt associated with a ranked result. Useful for discovery; potentially partial or stale. |
| Page content | Text extracted from a retrieved document. Retrieval may fail or return only part of a page. |
| Generated answer | A model-produced synthesis. It needs its own provenance and evaluation. |

For example, [Tavily Search](https://docs.tavily.com/documentation/api-reference/endpoint/search) exposes answer and raw-content options, while [Tavily Extract](https://docs.tavily.com/documentation/api-reference/endpoint/extract) retrieves content from URLs. Treat these as distinct outputs even when a provider can return several in one response.

## Keep your types honest

**App-owned result types · illustrative**

```typescript
type SearchHit = {
  url: string;
  title: string;
  snippet: string;
};

type RetrievedPage = {
  url: string;
  content: string;
  fetchedAt: string;
  status: 'complete' | 'partial';
};

type GeneratedAnswer = {
  text: string;
  sourceUrls: string[];
  provider: string;
};

// Never fill RetrievedPage.content with SearchHit.snippet.
```

> [!WARNING]
> **Missing content stays missing**
>
> If extraction fails, return a retrieval error or partial result. Do not relabel the search excerpt as the page's full contents.

## Build a deliberate pipeline

1. **Discover:** search with a bounded result count and explicit domain or time constraints where supported.
2. **Select:** choose which URLs warrant retrieval. Preserve titles and source URLs.
3. **Retrieve:** extract selected pages, keeping per-page failures and retrieval timestamps.
4. **Synthesize:** generate an answer only when requested, with references to the retrieved evidence.
5. **Evaluate:** check citation support, freshness, missing evidence, and output quality separately.

Retrieved pages are untrusted input. If a model consumes them, treat instructions found inside a page as content to analyze, not permission to change the application's behavior or disclose private data.

## Control cost and privacy

Avoid retrieving every hit by default. Limit result counts, extraction size, concurrency, and total time. Confirm current billing in the provider's own documentation; do not assume that search, extraction, and answer generation share a price or quota.

- Keep secrets and unnecessary personal information out of search queries.
- Use cache keys that include relevant query options and authorization scope.
- Preserve the provider and retrieval time when cached content is returned.
- Apply the same domain and data policies to fallback providers.

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.

Source: https://sdk-sdk.com/docs/search

---

# Database

Choose a database client without flattening transactions, authorization, or query semantics.

A database SDK carries more than queries. It also carries a connection model, an authorization model, and consistency guarantees your application relies on.

Guides · 5 min read

## Choose the access model

Start by deciding where queries run and whose identity they use. A browser data client, a server-side ORM, and a direct database driver solve related problems with different security and deployment requirements.

| Option | Evaluate first |
| --- | --- |
| Browser data client | User identity, row-level authorization, exposed schema, and permitted operations. |
| Server-side ORM | Schema and migration workflow, generated types, transactions, and runtime support. |
| Native driver | Connection lifecycle, pooling, parameterized queries, and database-specific features. |
| HTTP database client | Request semantics, transaction support, connection behavior, and service limits. |

## Preserve authorization

In a browser integration, access must be enforced by the data service rather than a hidden UI control. [Supabase's row-level security guide](https://supabase.com/docs/guides/database/postgres/row-level-security) explains how database policies control access and why privileged service credentials must stay off the frontend.

> [!WARNING]
> **Carry the actor through the boundary**
>
> A repository method should make the relevant user or tenant context explicit. Do not silently replace a user-scoped client with an administrative client when a request fails.

## Model product operations

**App-owned repository boundary · illustrative**

```typescript
type Project = { id: string; name: string };
type Actor = { userId: string; tenantId: string };

interface ProjectRepository {
  listForActor(input: {
    actor: Actor;
    limit: number;
    cursor?: string;
  }): Promise<{
    projects: Project[];
    nextCursor?: string;
  }>;
}

// Implement authorization, stable ordering, and cursor
// semantics in the adapter for your actual database.
```

Avoid a universal query object that pretends every database has the same joins, filters, ordering, or consistency. Keep product operations narrow and retain a native path for database-specific queries.

## Transactions and recovery

Use a real transaction for operations that require multiple writes to commit together. Check the installed client's transaction API, supported engines, and isolation behavior. The [Prisma transaction documentation](https://www.prisma.io/docs/orm/fundamentals/transactions) is an example of a primary reference to consult for a specific client.

Do not automatically fall back to another database after a failed write. A timeout leaves the original write's outcome uncertain, and a second database may have different state. Use durable operation identifiers and a deliberate reconciliation process.

## Test real database semantics

- Unit-test product behavior with deterministic repository fakes.
- Use an isolated real database to verify constraints, authorization, transaction rollback, and query behavior.
- Exercise pagination while records are inserted or deleted.
- Check the connection and concurrency model in the actual deployment environment.

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.

Source: https://sdk-sdk.com/docs/database

---

# Editorial criteria

How we evaluate source-backed SDK recommendations and corrections.

A useful directory is specific, verifiable, and clear about the tradeoffs. These are the criteria we use to evaluate additions and corrections.

Project · 3 min read

## What makes a good entry?

> [!NOTE]
> **Public submissions**
>
> A public submission channel is not available yet. This page documents our editorial criteria and the information needed to evaluate an entry.

Suggest an SDK when it solves a concrete developer problem and has a trustworthy source. Include the official package, repository, documentation, supported languages, and the category where a developer would expect to find it.

- Describe the job it does in plain language.
- Distinguish official SDKs from community-maintained clients.
- Link directly to evidence for runtime support and key capabilities.
- Include limitations that could change a developer's decision.
- Disclose your relationship to the project when relevant.

## Write source-backed notes

Prefer primary documentation and maintained repositories over comparison articles. Link to the page that supports the claim, identify the relevant package version where necessary, and avoid turning a documented optional feature into a universal guarantee.

**Contribution outline · copy and adapt**

```markdown
## SDK name

- Category:
- Official or community-maintained:
- Package / installation source:
- Repository:
- Official documentation:
- Supported runtimes (with source):

### Useful for
Describe one concrete integration.

### Capabilities and limitations
Link each technical claim to a primary source.

### Relationship to the project
Maintainer, user, or independent contributor.
```

## Improve an existing entry

Corrections are as valuable as new listings. Point out the exact statement, explain what changed, and include the official source. Useful fixes include a renamed package, an archived repository, a changed runtime requirement, or a capability that needs a more precise description.

> [!TIP]
> **Examples should be safe to reuse**
>
> Use placeholder credentials, identify illustrative application code, and verify actual provider imports. Do not invent SDK SDK packages or present an app-owned interface as a published API.

## Editorial principles

Keep recommendations independent and useful. Popularity alone does not establish quality, and a small library can be the right fit for a specific job. Explain the fit so readers can make their own decision.

- Be accurate before being comprehensive.
- Name costs, constraints, and missing capabilities when they matter.
- Keep comparison criteria consistent across providers.
- Send readers to the provider's current docs for changing details.

- [Browse the directory](/sdks) — Find an integration worth improving or exploring.
- [Review the selection guide](/docs/choosing-an-sdk) — Use the same evaluation questions in your contribution.

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.

Source: https://sdk-sdk.com/docs/contributing

---

# MCP server

Connect an AI agent to the public SDK catalog and documentation over Model Context Protocol.

The public MCP server provides read-only access to SDK listings, comparisons, documentation, and site pages. No account, API key, or authentication is required.

Project · 3 min read

## Connect

Use https://sdk-sdk.com/mcp as a remote Streamable HTTP server URL. Configure authentication as none. The server supports the 2026-07-28 protocol revision, including stateless requests and server/discover, plus stateless compatibility for older initialization-based clients.

**Remote MCP configuration**

```json
{
  "mcpServers": {
    "sdk-sdk": {
      "type": "http",
      "url": "https://sdk-sdk.com/mcp"
    }
  }
}
```

Client configuration formats differ. If your client offers a remote-server form, enter the endpoint URL directly. A browser GET of the endpoint returns 405; MCP clients use POST.

## Tools

| Tool | Purpose |
| --- | --- |
| search_site | Search full documentation, SDK records, code examples, and public pages. |
| list_content | List public content, filtered by kind, with offset pagination. |
| read_page | Read a complete known page as Markdown, including tables, links, and code. |
| list_categories | List SDK categories and entry counts. |
| list_sdks | Filter SDKs by category, kind, or search term. |
| get_sdk | Retrieve the complete SDK record, sources, caveats, and source review date. |
| compare_sdks | Compare two or three distinct SDKs. |

Every public page is also an MCP resource at its canonical URL. Use resources/list followed by resources/read, or the search and reading tools. Listings and documentation come from the same data as the website. Content changes when the site is deployed; live subscriptions are not provided.

## Fair-use limits

- 120 HTTP requests per minute per IP address, enforced by Vercel before the function runs. Counters are regional rather than a strict global per-IP quota.
- On HTTP 429, honor Retry-After when present. Otherwise wait 60 seconds with jitter before retrying. Agents sharing an outbound IP share its allowance.
- Maximum request body: 64 KiB. Search queries: 200 characters. List tools: at most 50 items per page. Comparisons: two or three distinct SDKs.
- Use search results and pagination to retrieve only what you need, and cache unchanged content within your workflow.

Requests do not execute code samples, call paid provider APIs, fetch arbitrary URLs, or modify site content. Source review dates describe editorial research, not runtime compatibility or a security endorsement.

## Protocol and browser clients

Modern requests must include the protocol metadata envelope and matching MCP-Protocol-Version, Mcp-Method, and applicable Mcp-Name headers. The official MCP SDK handles these fields. Malformed or unsupported requests receive protocol errors. Legacy clients can use the initialize handshake on the same endpoint.

Native and server-side agents normally omit Origin and can connect without credentials. Browser requests are limited to this site's origins; local development also permits localhost. Origin and Host validation defend the HTTP endpoint against DNS rebinding. This is not an authentication mechanism.

- [MCP 2026-07-28 specification](https://modelcontextprotocol.io/specification/2026-07-28) — Protocol specification and Streamable HTTP binding.
- [Machine-readable index](/llms.txt) — All public pages and canonical URLs.
- [Complete text export](/llms-full.txt) — The public catalog and documentation in one Markdown document.

SDK SDK is an independent discovery hub. Provider examples link to official documentation. App-owned examples are illustrative patterns you can adapt.

Source: https://sdk-sdk.com/docs/mcp

---

# searchSDK

Search across providers from twelve language and platform SDKs.

## Overview

searchSDK provides fourteen normalized web-search adapters and thirteen provider-native clients across fifteen providers. Server SDKs call providers directly; Swift, Android, React Native, and Expo SDKs use your authenticated HTTPS gateway. Native clients preserve provider-specific extraction, research, streaming, and job operations where supported. Public documentation includes language guides, a live playground, and a read-only documentation MCP endpoint.

**Best for:** Web, AI, and mobile applications that need explicit search-provider choice, traceable results, and access to native provider operations.

## SDK details

| Field | Value |
| --- | --- |
| Slug | searchsdk |
| Category | Search (search) |
| Kind | unified |
| Approach | Unified SDK: a shared interface across supported providers. Integration coverage and behavior can differ by provider. |
| Language | TypeScript / JavaScript, Python, Go, Java, Rust, C# / .NET, C, C++, Swift, Kotlin / Android, React Native, Expo |
| License | MIT |
| TypeScript source package | @belweave/search-sdk |
| Stage | Source alpha |
| Sources reviewed | 2026-10-29 |

## Availability & installation

Public MIT-licensed source is available on GitHub. Build the package for your language from the repository; registry publication is not claimed. For TypeScript, use the repository's Node version, build and pack the workspace, then install the generated tarball in your server application.

```shell
git clone https://github.com/Belweave/searchSDK.git
cd searchSDK
nvm use
npm ci
npm run build:sdk
npm pack -w @belweave/search-sdk
```

## Listed providers

- Context.dev
- TinyFish
- Exa
- Tavily
- Brave
- Perplexity
- Parallel
- Linkup
- Firecrawl
- You.com
- Serper
- SerpAPI
- Valyu
- SearXNG
- WonderSearch

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Twelve language and platform SDKs with documented runtime and capability differences
- Fourteen normalized search adapters and thirteen provider-native clients
- Explicit fallback, cancellation, deadlines, and provider provenance
- TypeScript policies for retries, bounded concurrency, caching, and in-flight deduplication
- Batch search with ordered outcomes and durable checkpoints for remote jobs
- Live server-side playground with visitor keys and a separate key-free fixture demo
- Language guides, Markdown exports, and a public documentation MCP endpoint

## Caveats

- Source-alpha APIs may change; build from a pinned revision and follow the language-specific installation guide.
- Mobile SDKs require your authenticated HTTPS gateway; provider keys stay server-side. Expo requires a development build.
- Policy APIs and native response handling differ by language. WonderSearch is native-only; Valyu and SearXNG have normalized adapters only.
- Authenticated comparative benchmarks are pending; a live playground result verifies that request, not every provider or account.
- Provider fees and account requirements remain separate. Remote job submissions do not have an exactly-once guarantee.

## Official links

- [Documentation](https://searchsdk.dev/docs)
- [Official website](https://searchsdk.dev)
- [Source repository](https://github.com/Belweave/searchSDK)

## Sources & verification

- [https://github.com/Belweave/searchSDK](https://github.com/Belweave/searchSDK)
- [https://searchsdk.dev/docs/sdks](https://searchsdk.dev/docs/sdks)
- [https://searchsdk.dev/docs/providers](https://searchsdk.dev/docs/providers)
- [https://searchsdk.dev/playground](https://searchsdk.dev/playground)
- [https://github.com/Belweave/searchSDK/blob/main/packages/sdk/package.json](https://github.com/Belweave/searchSDK/blob/main/packages/sdk/package.json)

Sources reviewed: 2026-10-29. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

A Belweave project, sharing ownership with SDK SDK.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/searchsdk

---

# dbSDK

Create, manage, and query PostgreSQL databases through one typed SDK.

## Overview

dbSDK combines a provider management API with a typed PostgreSQL query client. It makes transport capabilities and indeterminate write outcomes explicit, with optional Drizzle interoperability and resumable one-way database transfer. Its Drizzle bridge supports typed schema queries on dbSDK-owned connections, and dbsdk/orm re-exports the PostgreSQL schema-authoring surface.

**Best for:** Developers evaluating a shared control plane and typed PostgreSQL boundary across supported providers.

## SDK details

| Field | Value |
| --- | --- |
| Slug | dbsdk |
| Category | Databases (database) |
| Kind | unified |
| Approach | Unified SDK: a shared interface across supported providers. Integration coverage and behavior can differ by provider. |
| Language | TypeScript / JavaScript |
| License | Apache-2.0 |
| Source package name | dbsdk |
| Stage | Source-only · v0.1 |
| Sources reviewed | 2026-10-29 |

## Availability & installation

Build from the public repository, then install the built local package into your application. This project is not published on npm: the registry name dbsdk belongs to a different project. Follow the source installation guide for optional peers.

```shell
git clone https://github.com/pkyanam/dbSDK.git
cd dbSDK
pnpm install
pnpm --filter dbsdk build
```

## Listed providers

- PostgreSQL
- Supabase
- Neon
- PlanetScale Postgres

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Management operations for supported provider resources
- Parameterized PostgreSQL queries and normalized results
- Explicit capability checks and indeterminate-write errors
- Resumable one-way transfers with caller-owned checkpoints
- Drizzle query interoperability and PostgreSQL schema authoring
- Typed transactions, transport capabilities, and verified TLS connections

## Caveats

- Source build required; npm install dbsdk installs an unrelated package.
- Node.js 22.12+ and optional driver peers are required by the selected adapter.
- Current coverage is the PostgreSQL ecosystem, not every database engine.
- The README reports hosted Supabase, Neon, and PlanetScale verification as pending.
- Sync is not CDC or bidirectional replication and does not propagate deletes.

## Official links

- [Documentation](https://dbsdk.com/docs/getting-started)
- [Official website](https://dbsdk.com)
- [Source repository](https://github.com/pkyanam/dbSDK)

## Sources & verification

- [https://github.com/pkyanam/dbSDK](https://github.com/pkyanam/dbSDK)
- [https://dbsdk.com/docs/getting-started.md](https://dbsdk.com/docs/getting-started.md)
- [https://github.com/pkyanam/dbSDK/blob/main/packages/dbsdk/package.json](https://github.com/pkyanam/dbSDK/blob/main/packages/dbsdk/package.json)

Sources reviewed: 2026-10-29. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

An owned project in the SDK SDK / Belweave ecosystem. Listed with the same source and availability criteria as other projects.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/dbsdk

---

# Email SDK

One typed email API over multiple delivery providers.

## Overview

OpenCore's server-side adapter layer keeps transactional message calls consistent while using your existing provider accounts.

**Best for:** Transactional email with the option to change delivery providers.

## SDK details

| Field | Value |
| --- | --- |
| Slug | email-sdk |
| Category | Email (email) |
| Kind | unified |
| Approach | Unified SDK: a shared interface across supported providers. Integration coverage and behavior can differ by provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | @opencoredev/email-sdk |
| Stage | No stage specified |
| Sources reviewed | 2026-10-29 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @opencoredev/email-sdk
```

## Listed providers

- Resend
- Postmark
- SendGrid
- AWS SES
- Mailgun
- Brevo
- SMTP

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Typed adapter routing
- Delivery-aware retries and fallback
- Batch sends
- Offline testing adapters

## Caveats

- Usage telemetry is enabled by default, including an anonymous persistent identifier, outcomes, and redacted error reports. Opt out with EMAIL_SDK_TELEMETRY=0, DO_NOT_TRACK=1, or telemetry: false.
- Provider accounts and charges remain separate.
- Field support and scheduling differ by adapter.

## Official links

- [Documentation](https://email-sdk.dev/docs)
- [Official website](https://email-sdk.dev)
- [Source repository](https://github.com/opencoredev/email-sdk)

## Sources & verification

- [https://email-sdk.dev/docs](https://email-sdk.dev/docs)
- [https://email-sdk.dev/docs/adapters](https://email-sdk.dev/docs/adapters)
- [https://github.com/opencoredev/email-sdk](https://github.com/opencoredev/email-sdk)

Sources reviewed: 2026-10-29. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/email-sdk

---

# Social SDK

Typed social integrations with direct and managed routes.

## Overview

OpenCore combines platform adapters and optional managed backends, with capability checks and explicit per-destination outcomes.

**Best for:** Adding several social platforms while making capability differences explicit.

## SDK details

| Field | Value |
| --- | --- |
| Slug | social-sdk |
| Category | Social (social) |
| Kind | unified |
| Approach | Unified SDK: a shared interface across supported providers. Integration coverage and behavior can differ by provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | @opencoredev/social-sdk |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @opencoredev/social-sdk
```

## Listed providers

- Bluesky
- Instagram
- LinkedIn
- Threads
- TikTok
- X
- YouTube
- Zernio
- Post for Me
- PostFast
- Postiz
- Buffer

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Direct platform adapters
- Optional managed backends
- Capability manifests
- Deterministic mock backend

## Caveats

- Publishing, reads, analytics, and comments vary by platform.
- Direct platforms and managed backends are different integration routes.
- Server-side ESM; Node.js 22.12+ or Bun.

## Official links

- [Documentation](https://social-sdk.dev/docs/getting-started/installation)
- [Official website](https://social-sdk.dev)
- [Source repository](https://github.com/opencoredev/social-sdk)

## Sources & verification

- [https://github.com/opencoredev/social-sdk](https://github.com/opencoredev/social-sdk)
- [https://social-sdk.dev/docs/getting-started/installation](https://social-sdk.dev/docs/getting-started/installation)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/social-sdk

---

# Domain SDK

A shared lifecycle for customer domains on hosting platforms.

## Overview

OpenCore normalizes domain onboarding, DNS instructions, verification, and removal across supported deployment providers.

**Best for:** SaaS products onboarding customer-owned hostnames.

## SDK details

| Field | Value |
| --- | --- |
| Slug | domain-sdk |
| Category | Domains (domains) |
| Kind | unified |
| Approach | Unified SDK: a shared interface across supported providers. Integration coverage and behavior can differ by provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | @opencoredev/domain-sdk |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @opencoredev/domain-sdk
```

## Listed providers

- Vercel
- Cloudflare for SaaS
- Railway
- Render
- Netlify
- bunny.net

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Domain onboarding
- DNS and certificate records
- Verification polling
- Testing adapter

## Caveats

- Customer-domain management is different from registering or purchasing domains.
- DNS, certificates, and wildcard support depend on the provider.
- The application must enforce tenant ownership.

## Official links

- [Documentation](https://domain-sdk.dev/docs)
- [Official website](https://domain-sdk.dev)
- [Source repository](https://github.com/opencoredev/domain-sdk)

## Sources & verification

- [https://github.com/opencoredev/domain-sdk](https://github.com/opencoredev/domain-sdk)
- [https://raw.githubusercontent.com/opencoredev/domain-sdk/main/README.md](https://raw.githubusercontent.com/opencoredev/domain-sdk/main/README.md)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/domain-sdk

---

# Sandbox SDK

A shared API for local and hosted code sandboxes.

## Overview

OpenCore wraps sandbox lifecycle and execution APIs across Local and cloud providers, using provider SDKs and credentials for cloud execution.

**Best for:** Moving sandbox workflows between local development and cloud runtimes.

## SDK details

| Field | Value |
| --- | --- |
| Slug | sandbox-sdk |
| Category | Sandboxes (sandbox) |
| Kind | unified |
| Approach | Unified SDK: a shared interface across supported providers. Integration coverage and behavior can differ by provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | @opencoredev/sandbox-sdk |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @opencoredev/sandbox-sdk
```

## Listed providers

- Local (AgentOS)
- E2B
- Daytona
- Vercel Sandbox
- Upstash Box
- Ascii Box
- Railway Sandboxes
- Tenki

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Shared execution API
- Sandbox lifecycle management
- Automatic scope cleanup
- Local VM adapter

## Caveats

- The execution provider supplies the isolation boundary.
- Persistence, networking, and runtime features differ by provider.
- Local AgentOS is beta; supported runtimes include Node.js 22/24 and Bun 1.3+.

## Official links

- [Documentation](https://sandbox-sdk.app/docs)
- [Official website](https://sandbox-sdk.app)
- [Source repository](https://github.com/opencoredev/sandbox-sdk)

## Sources & verification

- [https://github.com/opencoredev/sandbox-sdk](https://github.com/opencoredev/sandbox-sdk)
- [https://sandbox-sdk.app/docs](https://sandbox-sdk.app/docs)
- [https://github.com/opencoredev/sandbox-sdk/security](https://github.com/opencoredev/sandbox-sdk/security)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/sandbox-sdk

---

# SMS SDK

One transactional SMS API across six messaging providers.

## Overview

OpenCore's adapter layer normalizes sends and verified webhooks, with fallback restricted to known provider rejection.

**Best for:** Transactional SMS with explicit failure and fallback behavior.

## SDK details

| Field | Value |
| --- | --- |
| Slug | sms-sdk |
| Category | SMS (sms) |
| Kind | unified |
| Approach | Unified SDK: a shared interface across supported providers. Integration coverage and behavior can differ by provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | @opencoredev/sms-sdk |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @opencoredev/sms-sdk
```

## Listed providers

- Twilio
- Telnyx
- Plivo
- Vonage
- Bandwidth
- Sinch

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Typed sends
- Known-rejection fallback
- Normalized verified webhooks
- In-memory testing adapter

## Caveats

- Unknown delivery outcomes stop fallback to reduce duplicate-send risk.
- Provider accounts, sender setup, and service charges remain separate.
- Server-side ESM for Node.js 20+ or Bun.

## Official links

- [Documentation](https://www.sms-sdk.com/getting-started/quick-start)
- [Official website](https://www.sms-sdk.com)
- [Source repository](https://github.com/opencoredev/sms-sdk)

## Sources & verification

- [https://github.com/opencoredev/sms-sdk](https://github.com/opencoredev/sms-sdk)
- [https://raw.githubusercontent.com/opencoredev/sms-sdk/main/README.md](https://raw.githubusercontent.com/opencoredev/sms-sdk/main/README.md)
- [https://www.sms-sdk.com](https://www.sms-sdk.com)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/sms-sdk

---

# Resend Node.js SDK

Resend's official client for its email API.

## Overview

A native provider SDK for sending text, HTML, or React-rendered email directly through Resend.

**Best for:** Applications committed to Resend's API and email workflow.

## SDK details

| Field | Value |
| --- | --- |
| Slug | resend |
| Category | Email (email) |
| Kind | provider |
| Approach | Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | resend |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install resend
```

## Listed providers

- Resend

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Transactional sends
- HTML and text bodies
- React email templates
- Typed API client

## Caveats

- Uses Resend only; it does not switch delivery providers.
- Sending from your own domain requires domain verification.

## Official links

- [Documentation](https://resend.com/docs/send-with-nodejs)
- [Official website](https://resend.com)
- [Source repository](https://github.com/resend/resend-node)

## Sources & verification

- [https://github.com/resend/resend-node](https://github.com/resend/resend-node)
- [https://raw.githubusercontent.com/resend/resend-node/main/readme.md](https://raw.githubusercontent.com/resend/resend-node/main/readme.md)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/resend

---

# Cloudflare TypeScript SDK

Cloudflare's official API client, including DNS and zones.

## Overview

A native Cloudflare REST client with typed requests and responses; useful when domain operations need Cloudflare-specific controls.

**Best for:** Direct control of Cloudflare DNS and zone resources.

## SDK details

| Field | Value |
| --- | --- |
| Slug | cloudflare |
| Category | Domains (domains) |
| Kind | provider |
| Approach | Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider. |
| Language | TypeScript / JavaScript |
| License | Apache-2.0 |
| Package | cloudflare |
| Stage | No stage specified |
| Sources reviewed | 2026-10-29 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install cloudflare
```

## Listed providers

- Cloudflare

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Zone management
- DNS record APIs
- Typed requests and responses
- Pagination helpers

## Caveats

- Cloudflare-specific; this is not a cross-host domain adapter.
- API permissions and product availability depend on your account.

## Official links

- [Documentation](https://developers.cloudflare.com/api/typescript/)
- [Official website](https://developers.cloudflare.com)
- [Source repository](https://github.com/cloudflare/cloudflare-typescript)

## Sources & verification

- [https://www.npmjs.com/package/cloudflare](https://www.npmjs.com/package/cloudflare)
- [https://developers.cloudflare.com/api/typescript/](https://developers.cloudflare.com/api/typescript/)
- [https://developers.cloudflare.com/api/typescript/resources/dns/subresources/records/methods/list/](https://developers.cloudflare.com/api/typescript/resources/dns/subresources/records/methods/list/)
- [https://raw.githubusercontent.com/cloudflare/cloudflare-typescript/main/package.json](https://raw.githubusercontent.com/cloudflare/cloudflare-typescript/main/package.json)

Sources reviewed: 2026-10-29. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/cloudflare

---

# E2B Code Interpreter

E2B's native SDK for stateful sandboxed code execution.

## Overview

Run code and inspect execution results in E2B sandboxes. The JavaScript package now lives in the main E2B monorepo.

**Best for:** AI code execution and analysis built directly on E2B.

## SDK details

| Field | Value |
| --- | --- |
| Slug | e2b-code-interpreter |
| Category | Sandboxes (sandbox) |
| Kind | provider |
| Approach | Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | @e2b/code-interpreter |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @e2b/code-interpreter
```

## Listed providers

- E2B

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Stateful code execution
- Execution results
- Custom sandbox templates
- Native sandbox client

## Caveats

- An E2B integration, not an adapter for other sandbox providers.
- The former code-interpreter repository points SDK development to the E2B monorepo.
- The current JS SDK manifest is MIT; the old template repository is Apache-2.0.

## Official links

- [Documentation](https://e2b.dev/docs)
- [Official website](https://e2b.dev)
- [Source repository](https://github.com/e2b-dev/E2B)

## Sources & verification

- [https://github.com/e2b-dev/code-interpreter](https://github.com/e2b-dev/code-interpreter)
- [https://raw.githubusercontent.com/e2b-dev/E2B/main/packages/code-interpreter-js/package.json](https://raw.githubusercontent.com/e2b-dev/E2B/main/packages/code-interpreter-js/package.json)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/e2b-code-interpreter

---

# Files SDK

A common file API across object and blob storage backends.

## Overview

Hayden Bleasel's independent adapter library normalizes file operations and exposes capabilities plus access to the native client.

**Best for:** Applications that want storage portability with explicit capability checks.

## SDK details

| Field | Value |
| --- | --- |
| Slug | files-sdk |
| Category | Files (files) |
| Kind | unified |
| Approach | Unified SDK: a shared interface across supported providers. Integration coverage and behavior can differ by provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | files-sdk |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install files-sdk
```

## Listed providers

- Amazon S3
- Cloudflare R2
- Vercel Blob
- Google Cloud Storage
- Azure Blob Storage
- Supabase Storage
- UploadThing

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Upload and download
- Signed URLs
- Capability checks
- Composable plugins

## Caveats

- Maintained separately from OpenCore; the package is unscoped.
- Selected provider SDKs are optional peer dependencies.
- Supported options vary by backend; unsupported options can throw.

## Official links

- [Documentation](https://files-sdk.dev/docs)
- [Official website](https://files-sdk.dev)
- [Source repository](https://github.com/haydenbleasel/files-sdk)

## Sources & verification

- [https://files-sdk.dev](https://files-sdk.dev)
- [https://files-sdk.dev/docs](https://files-sdk.dev/docs)
- [https://github.com/haydenbleasel/files-sdk](https://github.com/haydenbleasel/files-sdk)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/files-sdk

---

# AWS SDK for JavaScript — S3

AWS's official modular JavaScript client for Amazon S3.

## Overview

A native S3 client with typed commands for object storage operations. It exposes the service API rather than a normalized multi-storage abstraction.

**Best for:** Full access to Amazon S3's native API.

## SDK details

| Field | Value |
| --- | --- |
| Slug | aws-s3 |
| Category | Files (files) |
| Kind | provider |
| Approach | Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider. |
| Language | TypeScript / JavaScript |
| License | Apache-2.0 |
| Package | @aws-sdk/client-s3 |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @aws-sdk/client-s3
```

## Listed providers

- Amazon S3

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Object operations
- Typed service commands
- Modular client package
- Node.js and browser support

## Caveats

- S3-compatible services require their own endpoint and compatibility checks.
- Presigning and higher-level upload helpers are separate SDK packages.

## Official links

- [Documentation](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/s3/)
- [Official website](https://aws.amazon.com/sdk-for-javascript/)
- [Source repository](https://github.com/aws/aws-sdk-js-v3)

## Sources & verification

- [https://github.com/aws/aws-sdk-js-v3](https://github.com/aws/aws-sdk-js-v3)
- [https://raw.githubusercontent.com/aws/aws-sdk-js-v3/main/clients/client-s3/package.json](https://raw.githubusercontent.com/aws/aws-sdk-js-v3/main/clients/client-s3/package.json)
- [https://raw.githubusercontent.com/aws/aws-sdk-js-v3/main/clients/client-s3/README.md](https://raw.githubusercontent.com/aws/aws-sdk-js-v3/main/clients/client-s3/README.md)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/aws-s3

---

# UploadThing

Typed file upload routes and clients for web applications.

## Overview

UploadThing's official packages connect application upload flows to its managed service, with server middleware and optional framework UI packages.

**Best for:** Shipping an application upload flow with managed infrastructure.

## SDK details

| Field | Value |
| --- | --- |
| Slug | uploadthing |
| Category | Files (files) |
| Kind | provider |
| Approach | Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | uploadthing |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install uploadthing
```

## Listed providers

- UploadThing

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Typed file routes
- Upload limits
- Server middleware
- Upload completion callbacks

## Caveats

- Integrates with UploadThing's service rather than arbitrary storage providers.
- Framework UI packages such as @uploadthing/react install separately.
- Application authentication belongs in the route middleware.

## Official links

- [Documentation](https://docs.uploadthing.com)
- [Official website](https://uploadthing.com)
- [Source repository](https://github.com/pingdotgg/uploadthing)

## Sources & verification

- [https://github.com/pingdotgg/uploadthing](https://github.com/pingdotgg/uploadthing)
- [https://docs.uploadthing.com/getting-started/appdir](https://docs.uploadthing.com/getting-started/appdir)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/uploadthing

---

# Twilio Node.js SDK

Twilio's official server-side API helper library.

## Overview

A native provider client for creating and managing Twilio messages and other Twilio resources, with JavaScript and TypeScript usage.

**Best for:** Messaging applications that need Twilio's native API surface.

## SDK details

| Field | Value |
| --- | --- |
| Slug | twilio |
| Category | SMS (sms) |
| Kind | provider |
| Approach | Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider. |
| Language | JavaScript / TypeScript |
| License | MIT |
| Package | twilio |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install twilio
```

## Listed providers

- Twilio

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Message creation
- Typed API resources
- Environment-based credentials
- Pagination helpers

## Caveats

- Twilio-specific; it does not add cross-provider SMS fallback.
- Run on the server to protect credentials.
- Account and sender configuration are required for sending.

## Official links

- [Documentation](https://www.twilio.com/docs/libraries/node)
- [Official website](https://www.twilio.com)
- [Source repository](https://github.com/twilio/twilio-node)

## Sources & verification

- [https://github.com/twilio/twilio-node](https://github.com/twilio/twilio-node)
- [https://raw.githubusercontent.com/twilio/twilio-node/main/README.md](https://raw.githubusercontent.com/twilio/twilio-node/main/README.md)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/twilio

---

# Search SDK by Plust

An independent adapter library for multiple web search APIs.

## Overview

A shared webSearch interface normalizes results and can query several configured search providers in one call.

**Best for:** Evaluating a shared interface across multiple search services.

## SDK details

| Field | Value |
| --- | --- |
| Slug | plust-search-sdk |
| Category | Search (search) |
| Kind | unified |
| Approach | Unified SDK: a shared interface across supported providers. Integration coverage and behavior can differ by provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | @plust/search-sdk |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @plust/search-sdk
```

## Listed providers

- Google Custom Search
- SerpAPI
- Brave Search
- Exa
- Tavily
- SearXNG
- arXiv
- DuckDuckGo

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Normalized search results
- Multiple-provider queries
- Typed search options
- MCP integration

## Caveats

- An independent wrapper, not an official SDK from each search vendor.
- Provider API changes may outpace the adapters; compatibility was not runtime-tested.
- Credentials and provider charges remain separate.

## Official links

- [Documentation](https://github.com/PlustOrg/search-sdk#readme)
- [Official website](https://github.com/PlustOrg/search-sdk)
- [Source repository](https://github.com/PlustOrg/search-sdk)

## Sources & verification

- [https://github.com/PlustOrg/search-sdk](https://github.com/PlustOrg/search-sdk)
- [https://www.npmjs.com/package/@plust/search-sdk](https://www.npmjs.com/package/@plust/search-sdk)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/plust-search-sdk

---

# Tavily JavaScript SDK

Tavily's official web search and extraction client.

## Overview

A native client for Tavily's search, extract, crawl, map, and research APIs, intended for web-connected applications and agents.

**Best for:** Agent workflows that combine search and page extraction.

## SDK details

| Field | Value |
| --- | --- |
| Slug | tavily |
| Category | Search (search) |
| Kind | provider |
| Approach | Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | @tavily/core |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @tavily/core
```

## Listed providers

- Tavily

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Web search
- Content extraction
- Crawl and map
- Research tasks

## Caveats

- Tavily only; it does not normalize competing search APIs.
- Keyless search and extract have shared limits; other methods require a key.

## Official links

- [Documentation](https://docs.tavily.com/sdk/get-started/javascript)
- [Official website](https://tavily.com)
- [Source repository](https://github.com/tavily-ai/tavily-js)

## Sources & verification

- [https://github.com/tavily-ai/tavily-js](https://github.com/tavily-ai/tavily-js)
- [https://raw.githubusercontent.com/tavily-ai/tavily-js/main/README.md](https://raw.githubusercontent.com/tavily-ai/tavily-js/main/README.md)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/tavily

---

# Exa JavaScript SDK

Exa's official client for AI-oriented web search.

## Overview

Search the web, retrieve page contents, and request cited answers through Exa's native API.

**Best for:** Retrieval and cited-answer applications built on Exa.

## SDK details

| Field | Value |
| --- | --- |
| Slug | exa |
| Category | Search (search) |
| Kind | provider |
| Approach | Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | exa-js |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install exa-js
```

## Listed providers

- Exa

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Web search
- Content retrieval
- Answers with citations
- Streaming responses

## Caveats

- Uses Exa's service and API credentials.
- Search modes and optional output schemas have their own constraints.

## Official links

- [Documentation](https://docs.exa.ai)
- [Official website](https://exa.ai)
- [Source repository](https://github.com/exa-labs/exa-js)

## Sources & verification

- [https://github.com/exa-labs/exa-js](https://github.com/exa-labs/exa-js)
- [https://raw.githubusercontent.com/exa-labs/exa-js/master/README.md](https://raw.githubusercontent.com/exa-labs/exa-js/master/README.md)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/exa

---

# Brave Search MCP Server

Brave's official search integration for MCP clients.

## Overview

A tool server exposing Brave Search APIs to agents over MCP. This entry is an adjacent integration toolkit, not a conventional application SDK.

**Best for:** Agents consuming Brave Search through MCP tools.

## SDK details

| Field | Value |
| --- | --- |
| Slug | brave-search-mcp |
| Category | Search (search) |
| Kind | toolkit |
| Approach | Toolkit: building blocks for a workflow. Check its features and caveats for the scope of its provider integrations. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | @brave/brave-search-mcp-server |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @brave/brave-search-mcp-server
```

## Listed providers

- Brave Search

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Web and news search
- Image and video search
- LLM context tools
- STDIO and HTTP transports

## Caveats

- MCP server, not a unified search adapter or general-purpose SDK.
- Requires a compatible MCP client and Brave API credentials.
- Do not confuse the official server with third-party brave-search libraries.

## Official links

- [Documentation](https://api-dashboard.search.brave.com/documentation)
- [Official website](https://brave.com/search/api/)
- [Source repository](https://github.com/brave/brave-search-mcp-server)

## Sources & verification

- [https://github.com/brave/brave-search-mcp-server](https://github.com/brave/brave-search-mcp-server)
- [https://api-dashboard.search.brave.com/documentation](https://api-dashboard.search.brave.com/documentation)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/brave-search-mcp

---

# Firecrawl Node SDK

Firecrawl's official web search, scrape, and crawl client.

## Overview

Combine search discovery with page scraping, URL mapping, and asynchronous crawl jobs using Firecrawl's native service API.

**Best for:** Pipelines that need both search discovery and extracted web content.

## SDK details

| Field | Value |
| --- | --- |
| Slug | firecrawl |
| Category | Search (search) |
| Kind | provider |
| Approach | Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider. |
| Language | TypeScript / JavaScript |
| License | MIT (SDK) |
| Package | firecrawl |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install firecrawl
```

## Listed providers

- Firecrawl

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Web search
- Page scraping
- Site crawling
- URL mapping

## Caveats

- Current docs install firecrawl; @mendable/firecrawl-js also exists in the repository.
- The server repository is primarily AGPL-3.0; SDK licensing is MIT.
- Hosted access and self-hosted capabilities differ.

## Official links

- [Documentation](https://docs.firecrawl.dev/sdks/node)
- [Official website](https://firecrawl.dev)
- [Source repository](https://github.com/firecrawl/firecrawl)

## Sources & verification

- [https://docs.firecrawl.dev/sdks/node](https://docs.firecrawl.dev/sdks/node)
- [https://github.com/firecrawl/firecrawl](https://github.com/firecrawl/firecrawl)
- [https://raw.githubusercontent.com/firecrawl/firecrawl/main/apps/js-sdk/firecrawl/package.json](https://raw.githubusercontent.com/firecrawl/firecrawl/main/apps/js-sdk/firecrawl/package.json)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/firecrawl

---

# Prisma ORM

A typed data layer with contracts, queries, and migrations.

## Overview

The current Prisma ORM 8 documentation uses database-specific libraries. This catalog selects the PostgreSQL package; Prisma ORM 7 remains a separate supported path.

**Best for:** Evaluating Prisma's current typed PostgreSQL data layer.

## SDK details

| Field | Value |
| --- | --- |
| Slug | prisma |
| Category | Databases (database) |
| Kind | toolkit |
| Approach | Toolkit: building blocks for a workflow. Check its features and caveats for the scope of its provider integrations. |
| Language | TypeScript / JavaScript |
| License | Apache-2.0 |
| Package | @prisma/orm-postgres |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @prisma/orm-postgres
```

## Listed providers

- PostgreSQL

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Typed model queries
- Relations
- Transactions
- Schema migrations

## Caveats

- Prisma ORM 8 is a release candidate with a different API from Prisma ORM 7.
- MongoDB uses a separate early-access package; SQLite is experimental.
- Do not apply Prisma ORM 7's database support matrix or @prisma/client setup to this entry.

## Official links

- [Documentation](https://www.prisma.io/docs/orm)
- [Official website](https://www.prisma.io)
- [Source repository](https://github.com/prisma/orm)

## Sources & verification

- [https://www.prisma.io/docs/orm](https://www.prisma.io/docs/orm)
- [https://www.prisma.io/docs/orm/supported-databases](https://www.prisma.io/docs/orm/supported-databases)
- [https://github.com/prisma/orm](https://github.com/prisma/orm)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/prisma

---

# Drizzle ORM

A TypeScript ORM with SQL-like and relational query APIs.

## Overview

Define schemas in TypeScript and use a database-specific driver. Drizzle is an application data toolkit rather than a hosted database provider.

**Best for:** Developers who prefer SQL-shaped queries and TypeScript schema definitions.

## SDK details

| Field | Value |
| --- | --- |
| Slug | drizzle |
| Category | Databases (database) |
| Kind | toolkit |
| Approach | Toolkit: building blocks for a workflow. Check its features and caveats for the scope of its provider integrations. |
| Language | TypeScript / JavaScript |
| License | Apache-2.0 |
| Package | drizzle-orm |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install drizzle-orm
```

## Listed providers

- PostgreSQL
- MySQL
- SQLite

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- TypeScript schemas
- SQL-like queries
- Relational queries
- Optional migration tooling

## Caveats

- Install the driver appropriate to your database separately.
- drizzle-kit is separate migration tooling.
- Some current guides target the release-candidate channel; match documentation to the installed version.

## Official links

- [Documentation](https://orm.drizzle.team/docs/overview)
- [Official website](https://orm.drizzle.team)
- [Source repository](https://github.com/drizzle-team/drizzle-orm)

## Sources & verification

- [https://orm.drizzle.team/docs/overview](https://orm.drizzle.team/docs/overview)
- [https://orm.drizzle.team/docs/get-started-postgresql](https://orm.drizzle.team/docs/get-started-postgresql)
- [https://raw.githubusercontent.com/drizzle-team/drizzle-orm/main/drizzle-orm/package.json](https://raw.githubusercontent.com/drizzle-team/drizzle-orm/main/drizzle-orm/package.json)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/drizzle

---

# Supabase JavaScript Client

Supabase's official client for its backend services.

## Overview

A native Supabase platform client combining database queries with authentication, realtime subscriptions, storage, and function calls.

**Best for:** Applications using Supabase as a complete backend.

## SDK details

| Field | Value |
| --- | --- |
| Slug | supabase |
| Category | Databases (database) |
| Kind | provider |
| Approach | Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | @supabase/supabase-js |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @supabase/supabase-js
```

## Listed providers

- Supabase

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Database queries
- Authentication
- Realtime subscriptions
- Storage and functions

## Caveats

- Targets the Supabase stack rather than arbitrary SQL database servers.
- Browser access must be governed by database access policies; privileged service credentials belong on the server.

## Official links

- [Documentation](https://supabase.com/docs/reference/javascript/installing)
- [Official website](https://supabase.com)
- [Source repository](https://github.com/supabase/supabase-js)

## Sources & verification

- [https://github.com/supabase/supabase-js](https://github.com/supabase/supabase-js)
- [https://supabase.com/docs/reference/javascript/installing](https://supabase.com/docs/reference/javascript/installing)
- [https://supabase.com/docs/guides/database/postgres/row-level-security](https://supabase.com/docs/guides/database/postgres/row-level-security)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/supabase

---

# Neon Serverless Driver

Neon's PostgreSQL driver over HTTP and WebSockets.

## Overview

A native database driver designed for serverless and edge environments, with a fetch query API and node-postgres-compatible Pool and Client interfaces.

**Best for:** PostgreSQL access from environments where TCP connections are inconvenient.

## SDK details

| Field | Value |
| --- | --- |
| Slug | neon |
| Category | Databases (database) |
| Kind | provider |
| Approach | Provider SDK: a client for a specific provider’s API. Its interface and capabilities follow that provider. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | @neondatabase/serverless |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install @neondatabase/serverless
```

## Listed providers

- Neon PostgreSQL

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- HTTP SQL queries
- WebSocket Pool and Client
- Parameterized query tags
- Non-interactive HTTP transactions

## Caveats

- A driver, not an ORM or database migration toolkit.
- Interactive sessions require the WebSocket path.
- In serverless handlers, create and close WebSocket connections within the request.

## Official links

- [Documentation](https://github.com/neondatabase/serverless#readme)
- [Official website](https://neon.com)
- [Source repository](https://github.com/neondatabase/serverless)

## Sources & verification

- [https://github.com/neondatabase/serverless](https://github.com/neondatabase/serverless)
- [https://raw.githubusercontent.com/neondatabase/serverless/main/README.md](https://raw.githubusercontent.com/neondatabase/serverless/main/README.md)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/neon

---

# Kysely

A type-safe SQL query builder for TypeScript.

## Overview

Build SQL with types derived from your database interface, choosing a dialect and driver for the database you run.

**Best for:** Teams that want explicit SQL control with compile-time query types.

## SDK details

| Field | Value |
| --- | --- |
| Slug | kysely |
| Category | Databases (database) |
| Kind | toolkit |
| Approach | Toolkit: building blocks for a workflow. Check its features and caveats for the scope of its provider integrations. |
| Language | TypeScript / JavaScript |
| License | MIT |
| Package | kysely |
| Stage | No stage specified |
| Sources reviewed | 2026-10-22 |

## Availability & installation

Follow the official installation and account setup instructions.

```shell
npm install kysely
```

## Listed providers

- PostgreSQL
- MySQL
- Microsoft SQL Server
- SQLite

Provider lists describe documented scope, not guaranteed API or feature parity. For database toolkits, providers may name database engines rather than vendors.

## Features

- Typed SQL queries
- Database dialects
- Migration utilities
- Plugin system

## Caveats

- Requires a database driver and accurate schema types.
- It is a query builder, not a hosted database service.
- Current documentation requires TypeScript 5.4+ and strict mode.

## Official links

- [Documentation](https://kysely.dev/docs/getting-started)
- [Official website](https://kysely.dev)
- [Source repository](https://github.com/kysely-org/kysely)

## Sources & verification

- [https://kysely.dev/docs/getting-started](https://kysely.dev/docs/getting-started)
- [https://raw.githubusercontent.com/kysely-org/kysely/master/README.md](https://raw.githubusercontent.com/kysely-org/kysely/master/README.md)
- [https://raw.githubusercontent.com/kysely-org/kysely/master/LICENSE](https://raw.githubusercontent.com/kysely-org/kysely/master/LICENSE)

Sources reviewed: 2026-10-22. This records source review, not a runtime test or security endorsement. The license describes client/package source, not hosted-service terms. Installation may still require credentials, peers, and setup.

## Affiliation

SDK SDK is an independent directory and is not affiliated with this project.

[Back to the directory](/sdks)

Source: https://sdk-sdk.com/sdks/kysely