Agent onboarding

One-shot API migration instructions for coding agents.

Give a coding agent your OpenAPI spec, current docs or SDK context, and this page. It can choose the manual path or use Sourced free previews for SDKs, docs, and release checks, then use Sourced's standalone skill-file and MCP tools before anything goes live.

Unlimited previews. No credit card required.

01Details

What an agent should do first

01

Find the canonical OpenAPI file and confirm it parses.

02

Inventory the current SDK packages, docs host, custom domain, redirects, and publish settings.

03

If the team uses Stainless, read stainless.yml as the migration contract.

04

After explicit owner approval, run a Sourced preview before changing packages, docs DNS, npm, or PyPI.

02Details

Agent-safe operating rules

01

Never publish to npm, PyPI, GitHub, or a docs domain unless the user explicitly asks for that exact release action.

02

Treat downloads, Sourced-managed noindex docs URLs, and read-only registry metadata checks as safe review steps after approval. Sourced previews require upload approval, and any external CI/job dispatch requires exact approval even when it cannot publish.

03

Stop and ask before creating or signing into a Sourced workspace, uploading OpenAPI, stainless.yml, SDK source, docs source, or package metadata to any third-party service, or changing package names, DNS, custom-domain indexability, auth credentials, billing, or production repo branches.

04

Return a launch report with artifacts, smoke checks, registry readiness, docs readiness, and required approvals before any write.

03Details

Exact Sourced preview sequence

01

After user approval, create or sign into a Sourced workspace, then upload the OpenAPI spec from Projects or the Stainless migration flow.

02

For Stainless migrations, upload both OpenAPI and stainless.yml so package names, resources, auth, and publish settings can be preserved; if stainless.yml is missing, do not use the Stainless migration flow.

03

Wait for the run to finish, then inspect TypeScript SDK, Python SDK, docs preview, logs, and the compatibility report.

04

Use Release readiness for npm/PyPI/GitHub/docs dry-runs; a clean report only makes the migration eligible for review, and every external write still needs exact approval.

04Details

What Sourced gives the agent

01

Generated TypeScript and Python client packages with package metadata and smoke checks.

02

A private noindex docs preview with llms.txt, examples, redirect planning, and a DNS readiness check; paid production custom-domain cutover is separate and requires explicit approval.

03

Standalone skill-file guidance so coding agents know how to call the API without guessing.

04

A standalone MCP server generator for Cursor, VS Code, Claude Desktop, Cline, and Continue.

05

A WYSIWYG docs editing surface for team-owned narrative pages around the generated reference.

05Details

Manual path vs Sourced path

01

Manual path: validate OpenAPI, choose generators, write package metadata, build docs, create llms.txt, wire MCP tools, then test every artifact separately.

02

Sourced path: after approval, upload OpenAPI, review generated artifacts, download SDK/docs outputs, use the standalone skill/MCP tools as needed, run release readiness, and stop before each external write unless the user approves the exact repo and branch, npm package and version, PyPI project and version, docs domain, DNS records, and indexability change.

03

Free previews are enough for migration planning; paid workflows begin when a team wants repo sync, registry publishing, production docs hosting, or custom-domain cutover.