How the platform works

Registry

Every push is kept, scored for AI agents and checked for breaking changes. About Registry →

1. Create a project in your workspace and add a CI key.
2. Push your OpenAPI file from CI with our GitHub Action, or upload it in the browser.
3. Each push is kept as a version and scored from 0 to 100 by the agent-readiness rules.
4. The diff against the last version flags breaking changes, and suggested fixes come as a JSON Patch.

• The GitHub Action: push your spec from CI
• openapi-agent-check: the readiness rules as a CLI (MIT)
• openapi-agent-check on npm
• The agent-readiness check, free in your browser

API Reference

An interactive reference made from your spec, with no third-party script on the page. About API Reference →

1. Publish a version from your project page.
2. Readers get it at /r/<workspace>/<project>, built from your spec with a strict content security policy.
3. Embed it on your own site, or keep it on ours.
4. Every version you publish updates it, and readers can try each endpoint from the page.

API Client

Try any endpoint from the reference, and save the requests your team shares. About API Client →

1. Every hosted reference has Try it: requests go straight from the reader’s browser to your API.
2. For an API without CORS, Pro adds a proxy for the hosts you verify.
3. Your team saves requests in shared collections, and the ones you publish show to readers as examples.
4. Export a collection to Postman whenever you like.

Docs

Every docs site ships llms.txt, Markdown for every page and its own MCP server. About Docs →

1. Write your guides in Markdown, in your repository.
2. Push them from CI with a project key; they’re built once, at push.
3. Readers get them at /docs/<workspace>/<project> beside your reference, or on your own domain on Pro and up.
4. Agents get llms.txt, llms-full.txt, Markdown for every page and a docs MCP server, with nothing to set up.

• Our own llms.txt, the same format every docs site gets

SDKs

TypeScript and Python packages from your CI, under the MIT licence. About SDKs →

1. Add latitude10.sdk.json to your repository, naming your packages.
2. Your CI asks for an SDK made from a registry version.
3. You get a typed TypeScript package and a Python 3.11+ package, versioned from the breaking-change diff.
4. Your CI publishes them to your npm and PyPI accounts; the generated code is yours, under MIT.

MCP server (Agentify)

Every operation in your spec becomes an MCP tool at a URL, and your API credential stays sealed. About MCP server (Agentify) →

1. Turn on the MCP server for your project, and verify your API’s host.
2. Store your API credential: it’s sealed with AES-GCM and used only for calls to that host.
3. Hand agents a key, or on Pro let people sign in through your own identity provider.
4. Each tool call is one request to your API, and daily analytics show which tools agents use.

• The readiness check as an MCP server
• Publishing your MCP server: what each directory asks for