SDKs

Five first-party SDKs — TypeScript, Next.js, React, Go, and Python — all using ApiKey auth and local ES256 JWKS verification.

Qeet ID ships five first-party SDKs. The server SDKs authenticate with an API key (Authorization: ApiKey qk_…) and verify user access tokens locally against the public ES256 JWKS. The web SDKs run the hosted-login OAuth flow for you.

Available now

TypeScript & Next.js

@qeetid/sdk (server) + @qeetid/nextjs (App Router middleware, hosted-login flow, silent refresh).

React

@qeetid/react — <SignedIn> / <SignedOut>, useUser(), sign-in/out buttons.

Go

github.com/qeetgroup/qeetid-go — stdlib-only server SDK.

Python

qeetid on PyPI — httpx + local ES256 verification.

What the server SDKs give you

Local session verification — verify(token) checks the ES256 signature against the cached JWKS, then expiry/issuer/audience. No per-request network call.
Single-call authorization — can(...) / canAll(...) over GET /v1/check.
User & tenant management — typed CRUD with cursor pagination.
Typed errors + automatic retry/backoff on 429 and idempotent 5xx (honoring Retry-After).

the shape, across languages

TypeScript

const claims = await qeetid.sessions.verify(accessToken);
const ok = await qeetid.can({ user: claims.userId, tenant: claims.tenantId!, permission: "billing:write" });

Server SDKs use ApiKey; never ship the key

@qeetid/sdk, Go, and Python are server-side — they hold a qk_… API key. For browsers, use @qeetid/nextjs + @qeetid/react: the secret stays on the server and the session lives in an encrypted HttpOnly cookie.

Planned

Node-only (CommonJS), Rust, and React Native SDKs are planned and not yet shipped. Until then, use @qeetid/sdk (it runs on Node ≥18, Bun, Deno, and edge runtimes via Web Crypto) or call the REST API directly.