Customers keep asking for a Python SDK because your product now serves data teams and backend services that don't run TypeScript, and every one of them has been copy-pasting fetch calls or hand-rolling a requests wrapper while they wait. This is the "second language" moment: you have one SDK, it works, and now you need a second one built from the same spec without doubling your maintenance load. You have three real options — hand-write it, run an open-source generator, or use a hosted generation platform — and the right one depends on how many languages you expect to support after this one.
Why this moment always arrives
A TypeScript SDK covers your web-first customers well. But APIs that get traction attract a second audience: data engineers running Python notebooks, backend teams on Django or FastAPI, ML pipelines that need typed access without hand-parsing JSON. None of them want to write TypeScript, and most of them will not adopt your API seriously without a client that feels native to their language — proper type hints, idiomatic error classes, and a package they can pip install.
The request usually shows up as a handful of GitHub issues or sales calls before it becomes obvious it's a pattern, not a one-off. By the time it's undeniable, you're choosing under some time pressure, which is exactly when it's worth having the options laid out in advance.
Option 1: hand-write a Python client
What it looks like: a team member familiar with your API writes a Python package that mirrors the TypeScript SDK's shape — same resources, same method names adapted to Python conventions (snake_case, context managers, Optional[X] typing).
When it's right: your API is small and stable, and you expect Python to be the only second language you'll ever need. See the real cost of a hand-maintained client for the full accounting — the short version is that hand-writing is fine for one extra language on a slow-changing API, and expensive the moment either variable grows.
The catch: every future API change is now two edits instead of one, made by someone who has to remember to keep them in sync. This is exactly the setup that produces SDK drift — the Python client typically falls behind first, since it was added second and gets less ongoing attention.
Option 2: an open-source generator
What it looks like: point a tool like OpenAPI Generator or a similar OSS project at your spec, get a generated Python package, review and adjust the output, publish it yourself.
When it's right: you want full control over the generation pipeline, you're comfortable maintaining generator config and templates, and you have the engineering time to own the CI wiring, the publishing step, and the review process end to end. If your API is TypeScript-and-Python only and stable, the guide on generating a Python SDK from OpenAPI walks the OSS path in detail — it's a legitimate route, especially for a team that already runs its own release infrastructure.
The catch: the generator handles the code, but not the rest of "supporting a language" — see below. You still own docs, examples, versioning, and publishing, and you own keeping the generator's config current as your spec evolves.
Option 3: hosted generation
What it looks like: a platform that reads your OpenAPI spec — the same one your TypeScript SDK was generated from — and produces a Python SDK preview alongside it, with docs and a compatibility report, without you standing up generator infrastructure.
When it's right: you want Python (and likely a third or fourth language eventually) generated from the same source of truth as your existing SDK, with less ongoing pipeline maintenance. Sourced generates TypeScript and Python today — the two ecosystems where teams publish first — from the same spec push, so a Python SDK isn't a separate project — it's the same generation run producing a second language output. You can create a hosted docs and SDK preview from your repo free, with no credit card, and see the Python output before committing to anything.
The catch: you're trading control over generator internals for less maintenance surface. If you need Python-specific customization the platform doesn't support, that's a real constraint — check before you commit, and start free to verify the generated package matches what your Python consumers actually need before you tell them it's ready.
Comparing the three
| Hand-write | OSS generator | Hosted generation | |
|---|---|---|---|
| Setup effort | Low to start | Medium (config, templates, CI) | Low (point at spec) |
| Ongoing sync with API changes | Manual, per change | Manual pipeline run, or self-wired CI | Automatic on spec push |
| Docs and examples | You write them | You write them | Generated alongside SDK |
| Control over output | Full | High | Bounded by platform |
| Cost as you add a 3rd/4th language | Multiplies again | Add a generator target | Same pipeline, new output |
What "supporting a language" actually means
Generating the code is the visible part, but customers judge "we support Python" by more than whether pip install yourapi works:
- Docs in that language. Python examples with Python idioms, not TypeScript examples with the syntax swapped.
- Idiomatic examples. Context managers, type hints, and error handling that look like Python a Python developer would write, not a transliteration of the TypeScript SDK.
- Publishing, not just generating. A package on PyPI with a real version history, not a zip file in a GitHub release.
- Versioning discipline. Python and TypeScript versions don't have to match numerically, but breaking changes need to be communicated per language — a compatibility report per language catches this before a customer does.
Skipping any of these means the SDK exists but "Python support" doesn't, in the way a customer evaluating your API will judge it.
Honest scope: when the answer is "not yet"
If exactly one customer has asked for Python and your API changes rarely, the honest answer might be: point them at your OpenAPI spec and your existing docs, and revisit once the request is more than a one-off. Building a second language for a single requester, on a platform or pipeline you now have to maintain indefinitely, can cost more than it returns. Wait for the pattern — two or three independent asks — before committing to any of the three options above.
FAQ
How do I decide between hand-writing and generating a Python SDK?
Count expected future languages and your API's change frequency. One extra language, rarely changing API: hand-writing is reasonable. Multiple languages, or an API that changes weekly: generation pays for itself quickly — see the maintenance cost breakdown.
Will a generated Python SDK feel idiomatic to Python developers?
A good generator produces type hints, snake_case naming, and Python-native error classes rather than a literal port of the TypeScript SDK's shape. Check a generated sample against your own team's Python style before publishing — this is worth a manual review even with a trusted generator.
Do I need to publish the Python SDK to PyPI immediately?
No — most platforms and OSS generators let you preview the generated package first. Use the preview to confirm the surface is correct with real Python-consuming customers before committing to a public package name and version history.
What happens to Python SDK maintenance after the initial build?
The same forces that changed your TypeScript SDK — new endpoints, changed parameters, auth updates — apply equally to Python. Hand-written means a second manual edit per change; generated from the same spec pipeline means it updates alongside TypeScript automatically.
What if customers want a language beyond Python next?
The same three options apply again, but a generation pipeline that already covers TypeScript and Python typically adds a third language with far less new setup than hand-writing a third client from scratch would cost.