Client SDK Auto-Generation: Ship Native SDKs Across Languages Without Hand-Writing One

SDK Generation Strategy for Your New SaaS

Goal: If you ship a public API, your developer customers expect first-class SDKs in their language — TypeScript, Python, Go, Ruby, Java, Kotlin, PHP, C#, sometimes Rust or Swift. Hand-writing and maintaining 5-7 language SDKs is a permanent engineering tax: every API change becomes a multi-week multi-PR scramble; bugs in TypeScript get fixed but the equivalent issue in Go festers for months; type definitions drift from the OpenAPI spec. The pattern that works at scale: keep your OpenAPI spec as the single source of truth, use a managed SDK generator (Stainless, Speakeasy, Fern, Konfig) to produce idiomatic SDKs in every language you support, automate publishing through a CI pipeline, and maintain semantic versioning + clear deprecation paths. Avoid the founder traps of writing a TypeScript SDK by hand and adding more languages "when we have time" (you never will), using OpenAPI Generator's default templates and shipping cookie-cutter SDKs developers actively dislike, or skipping SDKs and assuming developers will hand-roll fetch calls (most won't — they'll use a competitor with better SDKs).

Process: Follow this chat pattern with your AI coding tool such as Claude or v0.app. Pay attention to the notes in [brackets] and replace the bracketed text with your own content.

Timeframe: Decide on the generator + first language SDK published in week 1. 3-5 language SDKs in week 2-3. Full release pipeline + docs + samples in week 4. Versioning + deprecation discipline as ongoing.

Why "We'll Hand-Roll the SDKs" Almost Always Fails

The same pattern shows up across founders:

Started with a hand-written TypeScript SDK; ten months later, no Python SDK. Your team has been busy. The Python user has been complaining. Eventually they pick a competitor that has Python and TypeScript and Go from day one. You "have time" only after you've already lost the user.
Wrote SDKs in 4 languages by hand. Each language is maintained by whoever wrote it. When that engineer leaves, the Ruby SDK starts decaying. Six months later it's three minor versions behind your API; users hit subtle bugs no one wants to debug.
Used OpenAPI Generator with default templates. The output is technically correct but unidiomatic — Java-style camelCase in Python, awkward error handling, no streaming, no retries, no auth helpers, weird type names. Developers prefer hand-rolling fetch over using your SDK.
Skipped SDK generation, assumed developers would just call your API directly. Most won't. The ones who will end up writing buggy retry logic, misformatting auth headers, hand-parsing JSON for typed access. They blame you when their integration breaks. Your competitor's "import the SDK and call .send()" pitch wins.

The version that works: OpenAPI spec is the source of truth, kept accurate and versioned. A managed generator (Stainless / Speakeasy / Fern / Konfig) produces idiomatic SDKs in every supported language. Generation runs in CI on every API change. SDKs are published to npm / PyPI / RubyGems / Maven Central / NuGet / pkg.go.dev / etc. with semver discipline and changelogs. Deprecations are signaled with Deprecation headers and SDK warnings.

This guide assumes you have already shipped Public API, have an OpenAPI spec generated and accurate, considered API Versioning, and have shipped API Documentation Tools (the SDK and docs are paired products). Cross-reference Webhook Signature Verification, Idempotency Patterns (SDKs should encode idempotency-key conventions), HTTP Retry / Backoff (SDKs should provide retry helpers), and API Pagination Patterns (SDKs should expose iterators).

1. Decide What Counts as "First-Class SDK"

Not every language needs the same investment. Tier the languages.

Help me decide which languages get first-class SDKs vs. which get
machine-generated-only vs. which get nothing for now.

Tier 1: First-class SDKs (heavy investment)
- Idiomatic API: language-native naming, error handling, async patterns
- Auth helpers (set token once, automatic header injection)
- Pagination iterators (auto-page; expose cursor; stream-style consumption)
- Retry + backoff defaults
- Streaming support (SSE / chunked) where the API supports it
- Idempotency-key handling
- Strong types (TS interfaces, Pydantic models, Go structs)
- Docs in-language with examples
- Published to native package registry
- Semver, changelog, migration guides on breaking changes

Tier 2: Machine-generated SDKs (lighter touch)
- OpenAPI Generator output, lightly customized templates
- Published to package registry but with caveats in README ("Beta / experimental")
- Acceptable for languages with smaller user bases

Tier 3: Skip; rely on raw HTTP
- Languages where the user base is genuinely tiny (<2% of API traffic)
- Document the curl examples; don't pretend to support them officially

My API and audience:
- Languages used by >5% of my API consumers (look at server logs / sign-ups
  metadata): [...]
- The "obvious" enterprise / marquee languages I want to be in even at <5%:
  [Java, C# usually for enterprise]
- Languages I might support post-Series A: [...]

Help me categorize my supported languages into tiers. The default Tier 1
shortlist for B2B API products in 2026:
- TypeScript / JavaScript (Node + browser)
- Python
- Go
- Ruby (if Rails / Stripe-style ecosystem fit)
- Java / Kotlin (for enterprise + Android)
- PHP (still huge installed base)
- C# / .NET (enterprise)
- Swift (if you have a strong iOS-mobile-developer audience)
- Rust (if your audience is systems / infra developers)

Tell me:
1. The Tier 1 languages I should ship from day one
2. Tier 2 candidates
3. Languages I should explicitly skip with documented rationale
4. The first-language priority order if I'm shipping serially (which is
   usually wrong — most generators ship multiple in parallel)

Default Tier 1 for most B2B APIs: TypeScript, Python, Go. Add Ruby if your audience overlaps with Rails-heavy customers (Stripe-influenced patterns). Add Java/Kotlin if you have enterprise customers. Add PHP if your audience includes WordPress / WooCommerce / Magento / Laravel ecosystems.

2. Pick a Managed SDK Generator

The 2026 market: Stainless, Speakeasy, Fern, Konfig, OpenAPI Generator (open-source, lower-quality default), Buf Connect (Protobuf-first, distinct paradigm).

Help me pick an SDK generator. The leading commercial options:

**Stainless**
- Founded by ex-Stripe team; positioning: "the Stripe SDK quality bar"
- Strong opinions on idiomatic API design across languages
- High-quality TypeScript / Python / Go / Java / Kotlin / Ruby
- Tight customization via Stainless config (JSON / YAML)
- Used by: Anthropic, OpenAI, Cloudflare, GitHub, others
- Pricing: enterprise; usage / language-tier based; free for OSS / qualifying startups
- Best for: production APIs where SDK quality is a competitive differentiator

**Speakeasy**
- Strong enterprise feature set; focus on TypeScript / Python / Go / Java / Ruby /
  C# / Swift / PHP / Unity
- OpenAPI overlay system for spec corrections without modifying the source
- Built-in CI / CD integration; GitHub Action native
- Pricing: free tier + paid plans
- Best for: teams wanting strong tooling integration + multiple languages

**Fern**
- Multi-language SDK generation + interactive docs
- Strong on docs integration (Fern docs is also a product)
- Languages: TypeScript / Python / Go / Java / C# (more added regularly)
- Pricing: free tier; paid plans for enterprise
- Best for: teams wanting SDK + docs as a unified product

**Konfig**
- Newer entrant; positioning on developer experience + low setup
- Generates SDKs + docs from OpenAPI
- Pricing: usage-based
- Best for: teams wanting fast time-to-first-SDK

**OpenAPI Generator (open-source)**
- Free; mature
- Default templates produce machine-feeling SDKs (work, but feel non-idiomatic)
- Customizable via Mustache templates — but customization is significant work
- 50+ language targets including obscure ones
- Best for: niche languages, internal-only SDKs, cost-constrained teams willing
  to invest in template customization

**Buf Connect (Protobuf-based)**
- Different paradigm: Protobuf as source of truth instead of OpenAPI
- Generates Connect-RPC SDKs in TypeScript / Go / Python / Swift / Kotlin / Java
- Best for: teams already using Protobuf / gRPC; not a fit if you've committed
  to REST + OpenAPI

My constraints:
- Languages I need (Tier 1 + Tier 2 from above): [...]
- Time-to-first-SDK budget: [days / weeks]
- API stability: [pre-1.0 changing weekly / stable / mature]
- Customization needs (custom auth, custom retry, brand-specific touches): [...]
- Budget: [free OSS / startup pricing OK / enterprise OK]
- Existing infrastructure: [GitHub Actions / GitLab CI / etc.]

Tell me:
1. Top 2 picks ranked, one-line rationale each
2. The wrong pick to explicitly avoid given my constraints
3. The integration steps for the top pick (OpenAPI spec → generator config →
   first SDK published to npm)
4. How to budget the ongoing maintenance time once SDKs are live

Decision heuristic:

Quality + multi-language priority + budget OK: Stainless or Speakeasy
Want SDK + docs unified: Fern
Cost-constrained, willing to customize: OpenAPI Generator (with significant template work)
Already committed to Protobuf: Buf Connect

3. The OpenAPI Spec — Make It a First-Class Artifact

Garbage spec → garbage SDKs. The spec is now a load-bearing artifact, not an afterthought.

Help me audit and improve my OpenAPI spec for SDK generation.

The spec needs to be:
- **Accurate**: every field matches reality, every status code documented,
  every error shape captured
- **Complete**: examples for every operation, request body, response
- **Idiomatic**: operationId names that produce nice method names
  (`createUser`, not `users_post_handler_v2`); tag-based grouping;
  consistent naming
- **Versioned**: semantic version on the spec itself; published alongside
  the SDK

How my spec is generated today:
[from code (FastAPI / NestJS / Hono / etc.) / hand-written / hybrid]

Improvements to make:
1. **operationId consistency**: every operation has a verb-noun
   operationId following the same pattern (e.g., `createUser`,
   `listUsers`, `getUser`, `updateUser`, `deleteUser`)
2. **Tag grouping**: operations grouped by resource (Users, Workspaces,
   Projects). Tags become the SDK's namespacing (e.g., `client.users.create()`)
3. **Error shape**: every error response has the same shape; documented
   once and referenced everywhere via $ref
4. **Pagination shape**: cursor-based pagination consistently; every list
   endpoint returns the same envelope
5. **Examples**: every request body has at least one example; every
   response has at least one
6. **Authentication**: securitySchemes documented; security requirements
   on every operation (or globally)
7. **Server URLs**: production + sandbox + EU + ... server URLs in the
   spec
8. **OpenAPI version**: 3.1+ for the latest features (json-schema
   alignment, web hooks, etc.)
9. **Custom extensions** for SDK generators: many generators support
   x-fern-*, x-stainless-*, x-speakeasy-* extensions for
   per-operation overrides

Audit my spec for:
- operationIds that produce ugly method names
- Inconsistent naming
- Missing error shapes
- Missing examples
- Anonymous (inline) types that should be named
- Missing pagination conventions
- Auth / security gaps

Build me a checklist of fixes prioritized by their impact on SDK quality.

Tip: when in doubt, generate an SDK against your current spec and READ THE OUTPUT. The shape of the SDK is the proof of how good your spec is. Bad SDKs always trace back to bad spec.

4. Generator Configuration — Take the Defaults Seriously

A generator's default output reveals taste. Take it as a starting point and tune.

Help me configure my SDK generator (assume Stainless / Speakeasy / Fern).

Per-language tuning:

**TypeScript**
- Package name: scoped to my org (`@acme/sdk` or just `acme-sdk`)
- Async: Promises by default (not callbacks)
- Errors: ApiError class with structured fields (status, code, message,
  request_id); subclasses for common errors (RateLimitError,
  AuthenticationError, ValidationError, ServerError)
- Streams: AsyncIterable<T> for paginated lists; ReadableStream for
  binary responses
- Auth: client constructor takes apiKey or token; auto-injects header
- Retry: configurable retry policy with sane defaults (3 retries,
  exponential backoff with jitter on 5xx + 429)
- Bundle target: ESM + CJS; types in .d.ts; tree-shakeable
- Browser + Node: works in both; uses native fetch where available

**Python**
- Package name: lowercase, hyphenated PyPI / underscored import
- Async: async clients available (asyncio); sync clients also exposed
- Models: Pydantic v2; strict typing
- Errors: ApiError + subclasses (same pattern as TS)
- Pagination: iterator that auto-fetches next page
- Streams: AsyncIterator / generator
- Retry: built-in with httpx; configurable
- Python version: 3.9+ (drop 3.8; verify your audience)
- Distribution: wheel + sdist on PyPI; type stubs included

**Go**
- Package name: `github.com/acme/acme-sdk-go`
- Idioms: `New(opts...)` constructor; functional options
- Errors: structured with errors.As / errors.Is support
- Pagination: iterator pattern with `Next()`
- Streams: Reader interfaces
- Retry: built-in via the http client wrapper
- Context.Context as first arg on every request
- Strict typing; no interface{} unless truly needed

**Ruby**
- Package name: hyphenated gem name
- Idioms: keyword args; bang vs non-bang where appropriate
- Errors: ApiError subclass tree
- Pagination: lazy enumerable
- Auth: simple block-based config
- Ruby version: 3.0+

**Java / Kotlin**
- Package name: reverse-DNS namespace (com.acme.sdk)
- Idioms: builder pattern for clients; CompletableFuture for async
- Errors: typed exception hierarchy
- Java version: 8+ for compatibility; or 11+ for newer features
- Kotlin coroutines for async

**For each language, tell me**:
1. The generator config snippet to produce idiomatic output
2. What to manually customize beyond defaults
3. The release-channel cadence (alpha → beta → 1.0)
4. The minimum viable QA before public release (smoke tests, lint,
   integration test against staging API)

Default that founders forget: every SDK should expose request/response objects with full type information. Untyped SDKs are a worse experience than raw fetch.

5. The Release Pipeline

Generation is one part. Publishing is the other. Build the pipeline once.

Build me the SDK release pipeline. The flow:

**On every API change**
- CI runs against the OpenAPI spec
- SDK generator runs (Stainless / Speakeasy / Fern) and produces updated
  SDK code
- Diff posted to a PR (in a separate SDK repo per language, OR in a
  monorepo with per-language directories)
- SDK PR auto-merges if it's an additive change; manual review for
  breaking changes
- Versioning bot bumps semver based on the diff (patch for additive,
  minor for new endpoints, major for breaking)

**On SDK PR merge**
- Tests run: smoke tests against the staging API; integration tests
  against canonical scenarios
- Build artifacts: tarballs, wheels, jars, gems
- Publish to language registries (npm, PyPI, RubyGems, Maven Central,
  NuGet, pkg.go.dev)
- Update changelog: auto-generated from the operation diff + manual notes
  for breaking changes
- Tag release in Git
- Publish docs site update (changelog page)
- Notify users: optional Discord / Slack / email digest of changes

**Per-language registry quirks**
- npm: scoped packages need `--access public`; 2FA on the publishing token
- PyPI: API tokens; trusted publishing via GitHub OIDC preferred
- RubyGems: gem signing optional but recommended
- Maven Central: requires signing keys + sonatype account; slow to set up
- NuGet: API key from nuget.org; signed packages
- pkg.go.dev: auto-discovered from Git tags
- Cocoapods (iOS): podspec; trunk push
- Cargo (Rust): cargo publish; needs crates.io token

**Deprecation handling**
- Deprecated operations emit warnings in the SDK at runtime (console
  warning, log entry)
- Sunset header (RFC 8594) propagated from API → SDK → user-visible
  warning
- Migration guides linked from deprecation warnings
- See [Product Sunsetting & Feature Deprecation](https://www.launchweek.com/4-convert/product-sunsetting-feature-deprecation)

**Versioning policy**
- Semver across all languages; SDK 1.x.y maps to API v1
- Breaking changes go in a major bump; supported overlap window
  documented (typically 12-18 months)
- Pre-1.0 SDKs (alpha / beta) explicitly labeled in README
- Each SDK release pinned to an API version (e.g., 1.4.2 of the SDK
  targets API version 2026-04-30)

Build me:
1. The CI workflow that generates and tests SDKs
2. The auto-publishing workflow with secret management
3. The changelog generator config
4. The deprecation-warning emission in the SDK code
5. The migration-guide template for breaking changes

6. SDK Quality Checklist

Idiomatic SDK feel is the difference between "developers love it" and "developers tolerate it." Run the checklist on every release.

Here's the SDK quality checklist. Score my SDK against each item.

**Initialization**
- [ ] Single-line client construction: `new Client({ apiKey: '...' })`
- [ ] Constructor takes options (timeout, retries, baseURL, headers)
- [ ] Sensible defaults; works with zero config beyond apiKey
- [ ] Environment variable detection for apiKey (`process.env.ACME_API_KEY`,
  `os.environ['ACME_API_KEY']`)

**Auth**
- [ ] Authentication header injected automatically
- [ ] Token rotation supported (update the client without re-construction)
- [ ] OAuth2 flow helpers if applicable (token refresh)
- [ ] Multi-tenant / multi-org support if applicable

**Calling the API**
- [ ] Methods named idiomatically per language convention
- [ ] Method signatures match the API resource hierarchy
  (`client.users.create({...})`, not flat `client.createUser({...})`)
- [ ] Required params surface as separate args; optional in an options
  object (TS, Python); functional options (Go); keyword args (Ruby, Python)
- [ ] Strong types; no `any` / no `Hash` / no untyped maps unless the
  field is genuinely dynamic
- [ ] Documentation strings on every method visible to IDE autocomplete

**Errors**
- [ ] Structured error class with status, code, message, request_id
- [ ] Subclasses for common error categories
- [ ] Error includes the original request data for debugging
- [ ] Errors reference docs URLs when applicable

**Pagination**
- [ ] Iterator / async-iterator pattern: `for await (const item of
  client.users.list())`
- [ ] Manual pagination available too (cursor-based access)
- [ ] Page size configurable

**Streaming**
- [ ] SSE / chunked-response endpoints expose stream interfaces
- [ ] Cancellation via AbortSignal / context

**Retries**
- [ ] Exponential backoff with jitter on 5xx + 429 by default
- [ ] Retry-After header respected
- [ ] Idempotency keys auto-generated for safe retries (where applicable)
- [ ] Configurable retry policy

**Idempotency**
- [ ] Idempotency-Key header support (Stripe-style)
- [ ] Auto-generated for non-GET operations OR explicit opt-in

**Webhooks**
- [ ] Webhook signature verification helper bundled
- [ ] Webhook event type definitions exported

**Observability**
- [ ] Hookable request/response interceptors for logging
- [ ] Request IDs surfaced in errors and successful responses
- [ ] OpenTelemetry support (tracing spans for each request) — bonus

**Distribution**
- [ ] Published to language-native package registry (npm, PyPI, RubyGems,
  etc.)
- [ ] Source available on GitHub
- [ ] License clearly stated (MIT or Apache 2.0 typical)
- [ ] README with quickstart + auth + first call + common errors
- [ ] CHANGELOG auto-updated on release

**Docs**
- [ ] In-language code samples in the API docs (toggle: TS / Python / Go /
  cURL)
- [ ] Stand-alone SDK docs site or section
- [ ] Migration guides for breaking changes

**Maintenance**
- [ ] Bug fixes triaged within 1 week
- [ ] Minor releases monthly; major releases coordinated
- [ ] Deprecation warnings fire before features are removed
- [ ] EOL policy documented (we support N versions back)

For my SDK, score each item: pass / fail / N/A. Then prioritize fixes.

7. Language-Specific Gotchas

Each language has traps that machine generators don't always catch.

Walk me through the language-specific quality issues to watch for.

**TypeScript**
- Bundle size: SDKs that pull in Axios, Zod runtime, etc. balloon to
  hundreds of KB. Aim for <50KB minified+gzipped for browser SDKs.
- Tree-shaking: ensure ESM build supports it; no top-level side effects
- Types vs. runtime: don't have unused-at-runtime classes; types should
  be erasable
- Worker compatibility: SDK should work in Cloudflare Workers, Vercel
  Edge, Deno; avoid Node-only APIs unless gated
- React Native compat: avoid `XMLHttpRequest`; use `fetch`

**Python**
- Async/sync split: don't force users to one or the other; offer both
- Pydantic v2 not v1 (massive performance + cleaner v2 API)
- Type stubs: include them; many SDKs get this wrong
- Python 3.9+ minimum is reasonable in 2026; check your audience
- httpx vs. requests vs. aiohttp: pick one; httpx is the modern default
- Pickle compatibility: SDK objects often need to be pickleable for
  multiprocessing

**Go**
- context.Context FIRST argument on every request method (non-negotiable)
- No `interface{}` unless truly required; use generics where they help
- errors.Is / errors.As compatibility on all error types
- Functional options for client config
- io.Reader for upload streams; io.Writer for download streams
- No global state; everything on the client struct

**Ruby**
- Keyword args for all options
- Lazy enumerable for pagination
- Block syntax for streaming where idiomatic
- Idempotency-key support per Stripe convention
- Rails compatibility: works inside ActiveJob and ActionController without
  extra config
- Ruby 3.0+ minimum; check the Gemfile

**Java / Kotlin**
- Builder pattern for client config (Java idiom)
- CompletableFuture or coroutines for async
- Maven Central distribution; Gradle compatibility
- Sealed classes / interfaces for error hierarchy
- JsonNullable<T> for "null vs. absent" distinction (OpenAPI gap)
- Android compatibility: avoid Java 11+ APIs if Android matters

**PHP**
- PSR-7 / PSR-18 for HTTP client abstraction (Guzzle compatible)
- PHP 8.1+ for typed properties + enums; older support increases
  maintenance burden
- Composer as the distribution channel
- Auto-loading: PSR-4 namespacing

**C# / .NET**
- Async/await everywhere
- IHttpClientFactory compatible
- nullable reference types annotated
- NuGet distribution; signed package
- .NET 6+ minimum reasonable in 2026

**Swift**
- async/await throughout
- Codable for serialization
- Swift Package Manager distribution
- iOS 14+ / macOS 11+ minimum reasonable

**Rust**
- async via tokio; expose both sync (via blocking) and async clients
- thiserror for error definitions
- Cargo features for optional dependencies
- Strict no-unsafe; no panic in normal paths
- crates.io distribution; semver discipline

For each language I support, audit my SDK against the gotcha list.

8. SDK Distribution and Discoverability

The SDK exists; users need to find it.

Help me make my SDKs discoverable and easy to adopt.

**Quickstart visibility**
- Homepage of my docs has a "pick your language" SDK selector
- Every API endpoint doc has a code sample in: cURL, TS, Python, Go (and
  any other Tier 1 language)
- Quickstart guides per language: install + auth + first API call in <5 min

**Package metadata**
- Every package's registry page (npm, PyPI, etc.) has:
  - Clear description
  - Tags / keywords for discoverability
  - Link to docs site
  - Link to GitHub
  - Author / org clearly attributed
  - License
  - Recent updates (releases tagged correctly)

**SEO and search**
- "How to use [my product] with [language]" is a real query developers
  Google
- SDK quickstarts indexed and visible
- README in the GitHub repo includes examples and auto-generated
  reference

**Developer marketing**
- Blog posts when major SDK versions ship
- Social posts to language-specific dev communities (e.g., r/Python,
  r/golang) when meaningful releases happen
- Podcast / conference appearances mentioning SDKs as part of DX
- Inclusion in awesome-* lists for the relevant language

**Sample apps**
- For each Tier 1 language, ship a complete sample app: realistic, not
  hello-world; deployable with one click
- Sample apps demonstrate auth, the most common workflows, error handling,
  pagination, retries
- Maintained: CI runs against the sample apps on every SDK release

Build me:
- The "select your language" docs component
- The metadata templates for each registry
- The blog post template for SDK releases
- The sample-app maintenance pipeline

Reference: see VibeReference: API Documentation Tools for the docs platforms that handle multi-language code samples natively (Mintlify, ReadMe, Stoplight, Scalar, Fern, Bump).

9. What Done Looks Like

You have shipped real SDKs when:

A developer in TypeScript / Python / Go can npm install / pip install / go get your SDK and make their first authenticated API call within 5 minutes
Every SDK is generated from your OpenAPI spec; spec changes propagate to all SDKs automatically
Every SDK has structured errors, retry helpers, pagination iterators, and idempotency support
Every SDK is published on every API change via CI, with semver and changelog
Documentation has language-toggling code samples for every endpoint
Every Tier 1 language has a maintained, runnable sample app
Deprecations propagate from API → SDK → user-visible warnings
Per-language quality issues (bundle size, type fidelity, async patterns) are tracked and fixed
A new engineer can read this doc + the generator config and understand the whole pipeline
Internal eng never hand-edits SDK code in the published artifact (all changes through the spec / generator config)

Mistakes to Avoid

Hand-writing SDKs in multiple languages. Maintenance tax kills you. Use a generator.
Using OpenAPI Generator with default templates and shipping unmodified. Output is unidiomatic; users prefer raw fetch.
Ignoring the OpenAPI spec quality. Bad spec → bad SDKs in every language. Fix the spec.
Shipping one language at a time, "we'll add Python next." Months become years; users churn.
No retry / pagination / streaming in SDKs. Users hand-roll these; they hate it; competitors win.
No structured errors. Generic "Error: 400" wastes the developer's time; structured + typed errors save it.
No semver discipline. Breaking change in a minor version = users angry forever.
No CI publishing. Manual publishing decays; SDKs fall behind the API.
No deprecation warnings in SDKs. Users hit removal day with no notice.
No webhook signature helpers. Users implement HMAC verification wrong; security incidents follow.
Generic SDK across all languages. Each language has idioms; respect them.
No sample apps. Documentation alone doesn't cut it; runnable code matters.
Skipping types in dynamic languages. Python without Pydantic / TS without strong types is a regression.
Ignoring bundle size in TS / browser. A 300KB SDK is unwelcome in a frontend app.
No EOL policy. Users on old SDK versions stuck with no clear support window.