Seller SDKs

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

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 implements the same contract with plain HTTP.

​

Get started