SDK reference
Official TypeScript and Go clients for the Suward merchant API, plus REST integration for Python and any other language. Typed across the full surface.
What every client gives you
- The full merchant surface, typed — payments, static wallets, deposits, quotes, simulations, and the public reference endpoints.
- Webhook verification — the TypeScript client ships an Ed25519 helper that takes the raw body, the signature header, your public key, and the timestamp header, so you never hand-roll the crypto. The Go client does not ship an equivalent helper yet; verify manually with
crypto/ed25519. → Verify, then trust - Typed errors — a single SDK error type carrying the HTTP status code and the parsed error body (
errorCode,message,args), so you branch on the stable code. → Errors & limits - Nothing you can’t do over REST. The SDKs are convenience, not capability — every call maps to a documented endpoint. If your language isn’t TypeScript or Go, the REST API is the whole surface, no SDK required. → API reference
Generated from the specification
SDKs are generated from the public OpenAPI specification, so new fields and endpoints arrive without breaking changes.
Choosing between an SDK and plain REST
| Use an SDK when | Use REST directly when |
|---|---|
| You want types and autocomplete (and, in TypeScript, the webhook helper) | Your language isn’t TypeScript or Go |
| You’re writing the integration from scratch | You already have an HTTP client and error convention |
| You want new fields to arrive with an upgrade | You want zero dependencies in a payment path |
Whatever you pick, the two future-proofing habits are the same: read enumerations from the API, and ignore unknown fields. → API reference
Something unclear? payments@suward.com — we treat every integration question as a documentation defect.