Block-based content needs Markdown/MDX cleanup.
Provider migration
Migrate from GitBook to Sourced
GitBook is broad knowledge-base software. Sourced is narrower: API docs, OpenAPI, SDKs, migration reports, and release checks. On this page: what to scan in your GitBook setup, the migration checks Sourced runs, and a preview of the generated SDK and docs you would get.
Unlimited previews. No credit card required.
01Checks
What to check
Git Sync does not automatically create SDK release checks.
API playground and custom domains need replacement configuration.
Public SEO URLs need redirects before the docs launch.
02Checks
Migration checklist
Export GitBook spaces as Markdown — most block-based content (callouts, hints, code groups) needs cleanup before round-tripping.
Decide which spaces become Sourced docs previews (API reference + SDK guides) vs which stay in GitBook (internal handbook, support KB).
If using GitBook Git Sync, fork the repo so Sourced can read OpenAPI without disrupting the GitBook integration during cutover.
Map every GitBook custom-domain space to a Sourced project; redirects must include /spaces/{id}/page/{slug} legacy URLs.
Plan the API Playground retirement — Sourced's generated reference handles 'try it' via the spec examples.
03Details
Why Sourced fits
Sourced focuses on API docs + SDKs; GitBook teams typically used it because it was easy, not because it was API-shaped.
OpenAPI → SDKs is a built-in workflow rather than a separate manual step.
Per-API-project pricing replaces GitBook's per-site/per-user model.
Honest trade-off: GitBook's editor + collaboration is meaningfully better for non-API knowledge bases (handbooks, runbooks, support docs). If most of your content isn't an API reference, GitBook stays the better pick.