Why Migrate?
| Concern | Direct API Calls | With the SDK |
|---|---|---|
| Authentication | Manual token management, refresh logic, thread safety | Automatic — handled by the SDK |
| Retries | Manual retry loops with backoff and jitter | Automatic — 429 and 5xx retried with exponential backoff |
| Pagination | Manual cursor tracking and page fetching | Automatic — iterators handle page boundaries |
| Error handling | Parse JSON, check status codes, extract request ID | Typed errors with IsNotFound(), IsRateLimited(), etc. |
| Idempotency | Generate and manage idempotency keys manually | Automatic — SDK generates keys for retried mutating requests |
Before and After
Authentication
Before — Manual token acquisition and injection:Pagination
Before — Manual cursor loop:Error Handling
Before — Raw status code checks:Migration Checklist
Use this checklist to migrate incrementally:- Install the SDK (Go, Python, TypeScript, Java)
- Replace token management code with SDK client construction
- Replace HTTP call sites with SDK service methods one at a time
- Replace manual error handling with typed SDK errors
- Replace pagination loops with SDK iterators
- Test each migrated call against Sandbox
- Deploy to production
Incremental Migration
You don’t have to migrate everything at once. The SDK client can coexist with your existing HTTP code. Start with the endpoints you call most frequently, then migrate the rest over time.The SDK uses the same underlying REST API — there are no behavioral differences between SDK calls and direct API calls.