REST is the shared contract for Search, Act, Host, Connect, and Account. The JavaScript SDK, Python SDK, and CLI are ways to use that contract; they do not create separate accounts or authorization models.
Keep API keys and service-account secrets on a trusted server. Browser and mobile applications should use Darwin’s user authorization flow, not an embedded server key.
REST API
The API Reference documents the live /api/v2 contract. Each operation identifies its scope, inputs, output, and approval behavior.
Public v1 product routes return 410 with code: "api_version_retired".
For delegated user access, request an OAuth token for the v2 resource https://api.darwin.so/api/v2. A token issued for the v1 audience is not a v2 credential. Darwin verifies the application, user grant, requested scopes, and resource on each call.
JavaScript SDK
Install @darwinso/sdk in a server-side JavaScript or TypeScript project:
The generated JavaScript SDK uses the same five families as REST.
Python SDK
Install darwin-sdk and import darwin_sdk in server-side Python:
Keep the token in a server-side secret manager. The Python client is generated from the same public OpenAPI document as REST and JavaScript.
CLI
Install the CLI for local development and account-controlled workflows:
Create an API key in Developer settings and configure it locally with darwin configure --api-key "darwin_...". For CI, use the DARWIN_API_KEY environment variable. The CLI uses the same v2 operations as the API and SDKs.
Approval
An API key, application credential, or AI client does not bypass account ownership, scopes, spending limits, or approval. Present an approval requirement to the accountable user; do not treat it as a retryable server failure. 
