Shipping and specialties
SDKs, quickstarts and docs
Raw HTTP is the contract. The kit around it — snippets, guides, samples, CLI — is how most people integrate.
Raw HTTP is the contract; SDKs are how most developers actually integrate. Good SDKs are generated or carefully maintained, idiomatic per language, and thin enough that docs still teach the underlying resources.
Stripe's docs culture — copyable snippets per language, tight coupling between reference and guides — is the benchmark many teams still chase. Twilio's early growth similarly rode "five lines to send an SMS" clarity.
Minimum viable DX kit
| Artifact | Job |
|---|---|
| Quickstart | Copy-paste to first successful call in under 10 minutes |
| API reference | Canonical, searchable, with try-it and exact error schemas |
| Guides | Task-oriented ("accept a payment", "verify a phone") |
| Sample apps | End-to-end repos that mirror real architectures |
| CLI / Workbench | Local triggers, webhook forwarding, request inspection |
| Changelog | What changed, whether breaking, migration notes |
Concept
The kit is part of developer experience. Time-to-first-call is usually a docs and tooling problem, not a missing endpoint.
Walking through the kit, not the verbs
That 47-minute first call in developer experience did not need a new endpoint. It needed a copy-.env button, a default region, and a CLI login. Median dropped to 9 minutes.
That is the Stripe / Twilio pattern in miniature: time-to-first-value in minutes with copy-paste snippets that actually run, plus inspectability so debugging is not a black-box support ticket. The changelog must say whether a change is breaking. SDKs should stay thin enough that the HTTP contract is still teachable.
DevRel as the human layer
Developer Relations is not conference swag. It is sample apps, office hours, Stack Overflow / Discord presence, early-access programs, and feedback routes into API review. Stripe operationalized API review as a cross-functional gate so every surface change meets a quality bar.
Community is a feedback channel with extreme bias (iteration and feedback) — still invaluable for integration pain you will never see in your own dogfood. Treat GitHub issues and Discord threads as research inputs with counts, not as a binding roadmap. A spike of "how do I rotate keys?" posts is a docs and dashboard problem, not a conference-talk problem.
Common mistakes
- Reference without a quickstart. People bounce before they call anything.
- SDKs that hide the resources. Docs should still teach the HTTP contract.
- Changelog that skips "is this breaking?" Integrators cannot plan.
Check yourself
Quickstart takes 47 minutes because of region and env-var confusion. Add an endpoint? No. Copy .env, default the region, CLI login. The API was fine; the kit was not.
Discord is full of "how do I rotate keys?" What kind of problem is that? Docs and dashboard. Not a conference talk, not a new endpoint.
Key takeaways
- Ship the kit: quickstart, reference, guides, samples, CLI/logs. SDKs are part of the product.
- Measure copy-paste to first 2xx in minutes. Most cliffs are in the kit.
- DevRel and community close the loop; API review protects the trust surface.
Further learning
Stripe's developer keynote — watch for the DX philosophy, not just the launches.
Next: developer funnels.
Related
Developer and API products
Treating APIs, SDKs and docs as products: developer experience and adoption.
Developer experience
Developers adopt a path from curiosity to production, measured in time-to-first-call, not endpoint count.
API design as UX
Resource names, errors, versioning and webhooks are the interface. Prefer additive compatibility.