> ## Documentation Index > Fetch the complete documentation index at: https://docs.zeroclick.ai/llms.txt > Use this file to discover all available pages before exploring further. # Seller SDKs > Official ZeroClick seller SDKs for TypeScript, Python, and Go: install, shared behavior, and how to choose. The seller SDKs implement the ZeroClick billing guard in your backend: they verify that a request really came from ZeroClick, check that the buyer can pay before you do the work, build the refusal responses ZeroClick expects, and report what was used. All three speak the same wire protocol and make the same decisions; they differ only in language idiom. | SDK | Package | Install | Requires | | ---------- | ----------------------------------------------------------------------------------------- | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | TypeScript | [`@zeroclickai/sellers`](https://www.npmjs.com/package/@zeroclickai/sellers) | `pnpm add @zeroclickai/sellers` | ESM; web-standard `Request`, `Response`, `fetch`, Web Crypto (current Node.js and compatible edge runtimes) | | Python | [`zeroclick-sellers`](https://pypi.org/project/zeroclick-sellers/) | `pip install zeroclick-sellers` | Python 3.10+ | | Go | [`cdn.zeroclick.io/sdks/sellers-go`](https://pkg.go.dev/cdn.zeroclick.io/sdks/sellers-go) | `go get cdn.zeroclick.io/sdks/sellers-go` | Go 1.24+ | All three are Apache-2.0 licensed. ## What every SDK does * **Verify first.** Every entry point verifies the `zc-signature` header before anything else. The signature is an HMAC-SHA256 over the raw request bytes. The SDK never checks an allowance for an unverified request. * **Decisions, not exceptions.** A guard returns an allow decision with the verified buyer context, or a deny decision that carries the exact response to return: `401` for a bad signature, the `402 payment_required` refusal for a business denial, or `503` under a fail-closed outage policy. Malformed configuration and API failures raise typed errors instead. * **Fail open by default.** If the allowance check fails without a usable answer, the configurable outage policy decides: `allow` (default), `deny`, or `throw`. A recognized `allowed: false` is always a `402`. The policy applies only after a signature verifies, so an unverified request is never served because the allowance API was down. The SDKs differ in how strictly they classify failures. The Go SDK treats any 4xx from the allowance API (a revoked key, an unknown service) as a hard error, never an outage. The TypeScript and Python SDKs route API errors through the policy. Each SDK's errors page documents its exact classification. * **Settle on success only.** Synchronous usage rides the `zc-usage` response header on 2xx responses; asynchronous usage goes through `reportUsage` with a seller-owned, derived idempotency key. No SDK retries automatically or invents idempotency keys. * **Split usage keys.** Pass one API key with both usage scopes, or a read key for guards and checks plus a write key for reporting. The split is useful when a separate worker reports usage. ## Differences that matter | | TypeScript | Python | Go | | -------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------ | ----------------------------------------------------------------------------------- | | Integration shape | Web-standard `Request` in, `Response` out; adapt your framework at the boundary | ASGI and WSGI adapters plus sync and async clients | Drop-in `net/http` middleware (`Meter`, `Identify`) | | Framework fit | Hono, Next.js route handlers, edge runtimes, anything web-native | FastAPI and Starlette (async); Flask and Django (sync) | `net/http`, chi, gorilla/mux directly; Echo and Gin via adapters; Fiber unsupported | | Concurrency model | async (Promises) | both: `create_seller` and `create_async_seller` | synchronous, context-aware | | Runtime validation schemas | Zod schemas via `@zeroclickai/sellers/contracts` | frozen dataclasses with validation | typed structs | | Encryption helpers | `@zeroclickai/sellers/encryption` subpath | top-level functions | separate `jwe` subpackage, so the core stays stdlib-only | | Secret loading helper | None | None | `SecretsFromEnv()` parses `ZEROCLICK_SIGNING_SECRETS` | Pick the SDK that matches your backend language. The core guard flow has the same capabilities in all three. If your backend is in another language entirely, the [REST walkthrough](/integrate/rest-walkthrough) implements the same contract with plain HTTP. ## Get started Web-native guard for Node.js and edge runtimes. Sync and async clients with ASGI and WSGI adapters. Standard middleware for net/http and friends.