Runtime Playbook

The backend SDK method surface is shared across:

• @wacht/backend (standalone runtime package)
• @wacht/nextjs/server
• @wacht/react-router/server
• @wacht/tanstack-router/server

The main difference is client access style and request/auth integration mechanics, not endpoint coverage.

Access style comparison (standalone vs framework adapter)

Standalone runtime:

import { initClient, users } from '@wacht/backend';

initClient({ apiKey: process.env.WACHT_API_KEY! });
await users.getUser('123');

Framework adapter:

import { wachtClient } from '@wacht/nextjs/server';

const client = await wachtClient();
await client.users.getUser('123');

Runtime-specific guides

• Node.js overview
• Extress
• Fartify
• NestJS
• Koa
• Hapi
• Restify
• Bun HTTP handlers
• Hono middleware and auth
• Cloudflare Workers API key/OAuth protected auth
• Netlify auth and header bridging

When to use which package

• Use @wacht/backend for Express/Fastify/Hono/custom servers, workers, and scripts.
• Use framework server adapters for framework-native server code.
• Keep backend API operations server-only in all cases.

End-to-end implementation checklist

1. Initialize client with server-only credentials.
2. Build one auth entrypoint per runtime (authenticateRequest or token extraction + getAuthFromToken).
3. Enforce permissions before backend API calls.
4. Standardize error responses for 401/403/429/5xx.
5. Add request IDs and structured logging.
6. Keep pagination bounded on management list routes.

Method parity expectation

Framework server adapters and @wacht/backend target the same backend API route surface. If you switch from one access style to another, your API method calls should stay equivalent.