SDKs and CLI
Official SDKs ship as thin wrappers over the public API. The CLI is the same engine that runs in production, exposed for local testing.
The SDKs are thin wrappers over the public API — TypeScript and Python — and the CLI is the same engine that runs in production, exposed for local testing. Nothing client-side re-implements platform behavior.
Pick the surface that fits the job: the SDK for typed in-process calls, the CLI for shell scripts and CI steps.
Because every surface mirrors the same REST contract, moving between them is mechanical: a request that works from the CLI works unchanged from either SDK with the same token and the same JSON body.
Languages
- TypeScript: `npm i @doesitdefend/sdk` (Node 20+).
- Python: `pip install doesitdefend` (Python 3.11+).
- CLI: `npm i -g @doesitdefend/cli` (Node 20+).
Version floors are part of the contract: Node 20+ for the TypeScript SDK and the CLI, Python 3.11+ for the Python SDK. Install from the public registries — npm and PyPI — under the @doesitdefend scope.
Pin the packages in CI like any other dependency. The wrappers track the public API instead of forking behavior, so the types you compile against stay aligned with the platform contract.
Usage
- Auth via `DID_API_TOKEN` env var.
- CLI mirrors the API one-for-one: `did runs create --profile=quick`.
- TypeScript SDK ships types for every response shape (Zod-validated).
Authentication reads DID_API_TOKEN from the environment rather than flags or config files. The CLI mirrors the API one-for-one (did runs create --profile=quick), and the TypeScript SDK ships Zod-validated types for every response shape.
The env-var convention keeps credentials out of shells, flags, and committed config: set DID_API_TOKEN once per environment and every surface picks it up.