GitBook spaces and the public/private mix.
Alternative
Sourced as a GitBook alternative.
GitBook is great for broad knowledge bases; it's a heavier fit when your docs are 80% API reference and 20% guides. On this page: a parity table, pricing comparison, and what to keep vs change in a migration.
Unlimited previews. No credit card required.
01Alternatives matrix
Sourced vs GitBook, side by side
Sourced and GitBook compared on the features API teams actually care about: OpenAPI ingestion, SDK generation, hosting, agent-readable output. Sourced-highlighted column is shaded.
| Feature | Sourced | GitBook |
|---|---|---|
| OpenAPI + reference | ||
| OpenAPI 3.0 / 3.1 ingestion | Partial | |
| Auto-generated reference pages | Partial | |
| Examples stay tied to spec | ||
| Docs operations | ||
| Custom-domain readiness | ||
| llms.txt / agent-readable | ||
| Sitemap + JSON-LD + OG | Partial | |
| WYSIWYG editor for general docs | ||
| SDKs and release | ||
| SDK generation in the same workflow | ||
| Compatibility report vs current SDK | ||
| Pricing model | ||
| Per-project pricing (predictable) | Partial | |
| Per-site / per-seat scaling | ||
Which one fits which team
- SourcedTeams whose docs are mostly API reference and who also ship SDKs from the same OpenAPI spec.
- GitBookTeams whose docs span multiple products (knowledge base, runbooks, internal wikis) and want a WYSIWYG editor for general content.
01Inventory
What to inventory before switching
Page URLs that external sites link to (need redirects).
Custom-domain setup.
Any GitBook-specific blocks or integrations.
02Details
What Sourced replaces cleanly
The API reference section, generated from your OpenAPI spec.
Custom-domain readiness and redirects.
llms.txt and SEO chrome.
SDK generation, if you also ship SDKs.
03Details
What stays in GitBook (or moves elsewhere)
Internal wikis or company-wide knowledge bases.
Heavy WYSIWYG-authored content.
Multi-product docs hubs without a strong API focus.