Client SDKs
TypeScript, Python, and .NET clients maintained alongside API behaviour — typed request models, versioned updates, and no hand-rolled HTTP.
Available client SDKs
| Language | Package name | Status | Runtime |
|---|---|---|---|
| TypeScript / Node.js | @esignature-erp/sdk | ✅ Live | Node ≥ 20; browser bundle via `fetch` |
| Python | endorsed-sdk | ✅ Live | Python ≥ 3.10 |
| .NET / C# | Endorsed.Sdk | ✅ Live | .NET 8+ |
All SDKs authenticate the same way (Bearer API key) and share the same versioned request/response contracts. The TypeScript client is authored in `packages/sdk`; Python and .NET quickstarts live in the SDK quickstart docs shipped with your sandbox.
What every SDK gives you
Typed request and response models
No stringly-typed dictionary access. Every API resource has a typed class with IDE autocomplete and compile-time checks.
Automatic retries
Network errors and transient 5xx responses are retried with exponential backoff. Configurable max attempts and backoff cap.
Bearer authentication
Pass your API key once at client construction. The SDK handles the Authorization header on every request.
Correlation ID propagation
Every SDK call returns the X-Correlation-ID from the response. Log it for support traceability.
Common questions
SDK quickstart — envelope in under 30 lines
Install the typed client, configure your credentials, and send your first envelope. The SDK maps 1:1 to the REST API — same shape, same errors, same versioning.
Get an SDK credential in one call
Claim a sandbox with `mode: sandbox` — the response body carries a scoped API key that works with every published SDK immediately.