Picking a stack

Picking a stack

Cryptohopper now ships 9 official SDKs plus a CLI. They're all functionally equivalent — same 18 API domains, same error taxonomy, same retry semantics. So the question isn't "which is best", it's "which fits what I'm already running."

Decision tree

1. One-off scripts, ops automation, terminal use? → cryptohopper CLI + the cli/ recipes.

2. Already in a Node.js codebase? (Express, Next.js, NestJS, serverless functions) → @cryptohopper/sdk.

3. Server-side Python? (FastAPI, Django, Airflow DAGs, Jupyter) → cryptohopper on PyPI.

4. High-performance backend, want tight binary, deploying to cloud functions? → Go (cryptohopper-go-sdk) or Rust (cryptohopper). Pick whichever your team already knows.

5. Rails, Sinatra, ops scripts? → cryptohopper on RubyGems.

6. Laravel, Symfony, WordPress, Magento integration? → cryptohopper/sdk on Packagist.

7. Mobile (Flutter cross-platform)? → cryptohopper-dart-sdk.

8. Native iOS / macOS / Linux server-side Swift? → cryptohopper-swift-sdk via SwiftPM.

9. Native Android / server-side Kotlin / Java interop? → cryptohopper-kotlin-sdk.

10. None of the above / hand-rolling HTTP / language without an SDK? → Raw curl reference. The contract is the same.

When to mix

• Web UI + ops scripts — use Node/Python in the app, CLI for ops. Same OAuth token works for both (CLI persists it at ~/.cryptohopper/config.json).
• Multiple services, different languages — totally fine. Each SDK is independently versioned and there's no shared state.
• Mobile + backend — mobile uses native (Swift/Kotlin/Dart); backend uses whatever your stack is.

Things that look like a choice but aren't

• HMAC signing — not in any v0.1 SDK. Bearer token only. Skip until v0.2+.
• Async vs sync — every SDK presents an async-ish API in its native idiom (Promises, coroutines, contexts, futures). The transport itself is async; you don't get to opt out.
• Mocked test client — every SDK's tests use mocks. Your tests should too — the Recipes wiki on each SDK shows how.