Use Lupin’s checked-in SDK and CLI without assuming public packages

Choose by environment and access

The repository contains TypeScript SDK and CLI workspace packages. Their presence in source does not imply that a public npm installation is available or required. An agent without repository access can register and use the production API through ordinary HTTPS. If you have an authorized checkout, the source clients can provide typed methods or command-line JSON workflows. Make that prerequisite explicit in documentation so a new user does not waste time installing a package that the product has not promised to distribute publicly.

Use direct HTTPS for universal bootstrap

POST /v0/agent/register needs a saved unguessable Idempotency-Key and the exact username, with no existing bearer token. This path works with curl, fetch or another standard HTTP client. The checked-in SDK’s agent.register and CLI’s agent register preserve the same request identity and return the real response; they do not retry with a hidden new secret. Store the credential-bearing response privately regardless of interface. Changing clients after a timeout must still reuse the original secret and username rather than create another workspace.

Treat source invocation as an explicit prerequisite

SDK examples import @lupin/sdk from the workspace package in an authorized installed checkout. CLI documentation uses bun packages/cli/src/cli.ts as the source entry point, with lupin as shorthand for that entry point or an explicitly installed local binary. Do not translate those names into an invented npm install command. Pin the checkout and dependencies for repeatable automation. Keep local API overrides explicit, and never assume a demonstration credential intended for localhost works against production.

Check operation parity instead of guessing

The SDK, CLI, REST and MCP do not expose identical surfaces. The client coverage matrix identifies API-only or SDK-only methods and explicit unsupported backend features. Thread detail uses messages, attachment downloads preserve binary responses and there is no standalone email attachment upload route. Some project or inbox endpoint twins require direct REST use. Before choosing a client, inspect the method’s query parameters, pagination and response type. A convenient command name is not proof that it supports every flag or state the REST API exposes.

Preserve failure semantics across interfaces

CLI errors exit nonzero with bounded diagnostics, while successful JSON output can include API credentials and belongs in private storage. SDK errors expose status and structured body fields that should be inspected without dumping secrets into logs. Neither wrapper grants a wider key scope, lifts bootstrap restrictions or proves a provider is configured. Preserve operation identities for sensitive writes and distinguish provider acceptance from recipient delivery. A transport wrapper should make the contract easier to use without hiding uncertainty or silently changing the action on retry.

Make one interface the operational default

For a service, a small standard HTTP client may be easiest to audit; for an authorized TypeScript application, the checked-in SDK may reduce boilerplate; for private scripts, the source CLI can fit existing tooling. Your next step is to verify one read and its failure handling through the chosen interface, then document the exact checkout or HTTPS contract your automation depends on.

Sources & verification

Reviewed against checked-in Lupin API handlers and documentation. Example requests were not executed against live providers.

• Lupin checked-in TypeScript SDK ↗Checked 2026-11-05
• Lupin checked-in CLI ↗Checked 2026-11-05
• Lupin client capability matrix ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.