api-sdk-designlisted

# API SDK design An SDK is the experience most developers have of your API; a good one makes integration a pleasure and a bad one sends them to a competitor. It must feel native in each target language, handle the hard parts (auth, retries, pagination) invisibly, and evolve without breaking the apps built on it. ## Method 1. **Feel idiomatic in each language.** An SDK should read like code written for that language: Pythonic in Python, idiomatic Go in Go (see kotlin-idioms, go-project-layout for what "idiomatic" means per language), naming and patterns matching the ecosystem's conventions. A thin transliteration of one language's SDK into another (Java-style getters in Python) reads as foreign and fights the user's instincts. 2. **Handle auth and resilience so users do not.** Token management and refresh (see oauth-flows), retries with backoff, timeouts, connection pooling, and rate-limit respect built in with sensible defaults (see api-client- design: the SDK is the definitive client): the user configures credentials and gets a robust integration. Making users implement resilience themselves guarantees most integrations do it badly. 3. **Make the common case one obvious line, the rare case possible.** The 90% use case (create a resource, list with pagination) is trivial and discoverable (auto-complete-friendly, see api-surface-minimalism); advanced control (custom retries, raw response access, timeouts per call) is