Build on Spunto
Four ways in — call the API, let an agent drive it over MCP, plug your service in as an app, or sign people in with their Spunto account.
Spunto is built so that what it connects to is not hardcoded. Repositories come from a git host app, sandboxes run on a runtime app, tasks run under an agent app — and GitHub, Google Cloud or the machines you bring yourself are each one of those apps, talking to the platform over the same signed HTTP contract a third party would use.
That leaves four ways to build something with Spunto, depending on which side starts the conversation.
Call Spunto — REST API
Create projects, start sandboxes, run commands and delegate tasks from a script or CI, with a scoped API key.
Let an agent drive — MCP
Point Claude Code, Cursor or your own agent at the MCP server and it can find and read your projects.
Let Spunto call you — apps
Implement a capability — a git host, a place to run sandboxes — and organizations install it like they install GitHub.
Sign people in — Connect with Spunto
OAuth 2 with PKCE: know who a user is and which organizations they belong to, with their role.
| You want to… | Use | Who authenticates |
|---|---|---|
| Automate Spunto from a script, a CI job or a bot | REST API | You, with an spk_ API key |
| Give an AI agent tools over your organizations | MCP server | The same spk_ key |
| Make your forge, your cloud or your machines available to Spunto organizations | An app | Spunto, signing every call it makes to you |
| Put a "Connect with Spunto" button on your own site | Connect with Spunto | The user, on Spunto's consent screen |
The first two are outbound — your code calls Spunto. The last two are inbound — Spunto calls your code, or sends users to it.
Everything on these pages is open to every organization. An owner or admin registers an app from Settings → Developer apps, and can use it in their own organization straight away. It reaches other organizations once Spunto has reviewed it → Publishing an app.
An app declares, in a manifest it serves, which capabilities it implements — git, runtime — and which of their operations. An organization installs it (an owner or admin connects it, and the app keeps whatever credential that produces). When the platform needs, say, a credential to clone a repository, it looks up which installed app implements git.cloneCredential and calls it — a signed POST to the app, with the organization's id and the operation's input. The platform never holds the app's credentials: it asks.
→ Building an app walks through it end to end.