liblab is a real SDK generator — as of September 2026 it's part of Postman, acquired in November 2025, and its CLI still generates SDKs in six languages plus Terraform providers from a liblab.config.json file. A migration to Sourced makes sense when your actual surface is narrower than that: TypeScript and Python SDKs, hosted docs, and llms.txt from one OpenAPI spec, without owning a CLI config or a Postman workspace — and, unlike liblab today, from one of the last two independent, vendor-neutral hosted SDK-and-docs platforms still standing (see the consolidation table). If you need liblab's other four languages, this is a scope change, not a full replacement: keep those languages running on liblab in parallel and read the "what does NOT map" section below before you start.
When the migration makes sense
Consider Sourced when:
- TypeScript and Python are the SDKs your customers actually install.
- You want a hosted docs preview and
llms.txtgenerated from the same spec that produces the SDKs, not a separate docs tool. - You'd rather not maintain a
liblab.config.jsonand a CI job that runsliblab buildon every spec change. - You want free, no-card previews before anything reaches npm, PyPI, or a public docs domain.
- You don't need liblab's Terraform provider generation or its now-broader Postman workspace integration.
Stay with liblab (or its Postman-integrated successor) if your published SDKs already include C#, Java, Go, or PHP, or if your team is standardizing on Postman for the rest of the API lifecycle and wants SDK generation in the same place.
Inventory the current liblab setup
Find these first:
- the canonical OpenAPI (or Postman Collection / Swagger) spec liblab points at
liblab.config.json— per liblab's own docs, its top-level fields includesdkName,specFilePath,languages,auth,customizations,languageOptions, andpublishing- the
output/directory structure — liblab's quickstart generates one subfolder per language (output/typescript,output/python,output/csharp, and so on), each meant to be pushed to its own repo - any custom hooks or template overrides referenced in
customizations - package names and registry targets per language (npm scope, PyPI project name, NuGet, Maven, etc.)
- the GitHub Action wiring, if you're using liblab's SDK-update action to open PRs against customer-facing repos
- auth env var names and the quickstart example baked into each generated README
As with any generator migration, the risk isn't a build failure — it's a package name, import path, or auth env var that quietly changes and customers only find out after upgrading.
What actually maps to Sourced
Your OpenAPI spec is the portable asset. Everything liblab derives from it — SDK method shapes, resource structure, the generated docs content — Sourced re-derives from the same source. What doesn't carry over automatically is the liblab.config.json itself: Sourced doesn't read that file format, so package names, auth env-var prefixes, and customizations need to be re-entered or confirmed during setup, the same way they would moving to any other generator.
For the languages both tools support — TypeScript and Python — compare:
- package name and module/import path
- constructor shape and auth setup
- method names and resource tree
- pagination helpers and error classes
- the generated README quickstart example
- default base URL, retry, and timeout behavior
For docs, compare custom domain, route structure, code examples, and whether llms.txt and a sitemap exist today (liblab's core product is SDK generation; docs hosting isn't a standard part of the CLI output the way it is with Sourced).
The Sourced migration path
- Upload the same OpenAPI spec (or export it from your Postman Collection, if that's liblab's current source) to Sourced.
- Generate TypeScript and Python SDK previews.
- Generate the hosted docs review site and
llms.txtfrom the same upload. - Compare the SDK public surface — methods, auth, errors, pagination — against your currently published liblab-generated packages, and confirm package names and env-var prefixes match what customers already have installed.
Nothing is published, pushed, or made indexable during this — it's a side-by-side comparison you review before approving anything.
What does NOT map — say it plainly
liblab, per its own docs, generates C#, TypeScript, PHP, Java, Go, and Python SDKs, plus Terraform providers. Sourced's generated SDKs focus on TypeScript and Python today — the two ecosystems where most API teams publish first. For C#, Java, Go, PHP, or a Terraform provider, the move is a parallel run, not a cutover: keep those languages on liblab (or another generator) and use Sourced for the TypeScript/Python-plus-docs slice, or hold off entirely until every language has an approved destination. There's also no equivalent to liblab's customizations hooks system or its Postman workspace integration in Sourced — confirm neither is load-bearing for your release process before you migrate.
Comparison
| Dimension | liblab | Sourced |
|---|---|---|
| Owner (as of Sept 2026) | Postman (acquired liblab, Nov 2025) | Independent |
| Languages | C#, TypeScript, PHP, Java, Go, Python, Terraform | TypeScript, Python |
| Config | liblab.config.json, CLI-driven (liblab init, liblab build) |
Dashboard/upload-driven, no local config file to maintain |
| Hosted docs | Not a core CLI output | Yes, generated from the same spec |
| llms.txt | Not published in liblab's own docs | Yes |
| Compatibility diff vs. live SDK | Not published in liblab's own docs | Yes |
| Free tier | MCP generation has a published free/pay-as-you-go tier; SDK generator pricing isn't fully public | Unlimited SDK/docs previews, 2 hosted noindex docs sites, no card |
Honest scope
If your team is shipping SDKs in four or more languages, or you're already standardizing on Postman for API design, testing, and docs in one place, liblab inside Postman is a reasonable place to stay — see "what does NOT map" above for the specific gap. The migration makes the most sense for teams whose real customer footprint is TypeScript and Python, who want hosted docs and llms.txt out of the same pipeline, and who'd rather not own a CLI config file and a CI job for a generator step.
FAQ
Is liblab still actively maintained?
Yes. As of September 2026 it operates as part of Postman, following a November 2025 acquisition, with its own docs, CLI, and pricing pages still live at liblab.com.
What is liblab's config file called?
liblab.config.json, per liblab's CLI config documentation. It sets the SDK name, spec file path, target languages, auth, customizations, and publishing settings.
Does Sourced support the same languages as liblab?
Not the full set — see "what does NOT map" above for the exact gap and the parallel-run option for the languages Sourced doesn't cover yet.
Can I use liblab and Sourced at the same time?
Yes. Nothing about running a Sourced preview requires removing liblab. Some teams keep liblab for languages Sourced doesn't cover and use Sourced specifically for the TypeScript/Python-plus-docs slice.
Does migrating change my package names or auth setup?
Not automatically, and that's the risk to manage. Sourced doesn't read liblab.config.json, so package names, import paths, and auth env-var prefixes need to be confirmed during setup — compare them against your live liblab packages before publishing anything.
Where do I start?
Run your OpenAPI spec through the OpenAPI validator first, then create hosted docs from your repo or start free to see the TypeScript and Python SDK previews side by side with what liblab currently publishes.
Bottom line
Migrate from liblab to Sourced when TypeScript and Python are the SDKs that matter and you want hosted docs and llms.txt from the same spec upload, without owning a CLI config file or a build pipeline for it. If C#, Java, Go, PHP, or Terraform providers are still part of what you ship, plan for those to keep running on liblab in parallel rather than assuming a single clean cutover — see "what does NOT map" above.
Try Sourced free, see liblab's current pricing directly since packaging can move, or read the Speakeasy migration guide if language breadth is the deciding factor for you too.