The API
An API on StartupBuilder is a published promise of Verbs on Nouns, compiled from one definition, with StartupBuilder built from the same parts.
An API on StartupBuilder is a published promise: these Verbs on these Nouns, for these callers, on these terms. Every part compiles from one definition, and StartupBuilder keeps the same promise to its own callers.
Seven parts, one definition
| Part | The question it answers | Where it comes from |
|---|---|---|
| Contract | What can be called, with what input and output | Nouns and Verbs |
| Address | Where each Interface answers | A Domain and a path per Interface |
| Caller | Who calls, and for whom | Keys from Identity and Roles |
| Terms | What a call costs and how far it goes | Offers, Meters and Limits |
| Execution | What runs a call | The Function behind each Verb |
| Change | How the contract grows without breaking callers | Changes and Versions |
| History | What happened | Actions and Events |
A Startup authors the Nouns, Verbs and Offers. The rest derives: routes, OpenAPI, the SDK, the CLI, the MCP server, errors, docs, the key screen, the usage screen and the changelog. Every record behind it lives in the Database.
Two kinds of caller
Every Startup's API serves two kinds of caller. Its Workers run the business: they publish Offers, answer Conversations and close Periods. Its Customers use the Product: they look up opening hours or reschedule an appointment.
Both reach the same records through the same Verbs. They differ in address, scope and brand.
| Workers and tests | Customers | |
|---|---|---|
| Address | https: | https: |
| Scope | Every Verb their Role grants, across the Startup | Their own Tenant, and the Verbs their Role grants |
| Names | StartupBuilder's SDK, CLI and MCP server | The Startup's own packages, docs, status page and error pages |
Customers never see api.sb. No address, package, header or error page they meet names the platform.
StartupBuilder is built the same way
StartupBuilder is the Product of a Studio, startups.studio, which runs as a Startup like any other. Its API at api.sb, its reference, SDK, CLI and MCP server compile through the same projection as every Startup's.
Every tool StartupBuilder gives founders, each Startup gives its Customers:
| StartupBuilder gives | Each Startup gives its Customers |
|---|---|
| Keys with a test twin and rotation | The same keys, in the Startup's Portal |
| Usage against their Limits | Usage against each Limit of their Offer |
| A request log with the checks each call passed | Their own requests, with the same checks |
| A version pin and a changelog | A pin on the Startup's versions, and its changelog |
The startup-builder SDK, CLI and MCP server | An SDK, a CLI and an MCP server named for the Startup |
No route is written by hand. A need the generic routes cannot meet changes the abstraction for every Startup, and a tool the platform keeps for itself is a defect.
What stays a choice
Three things stay open per Verb:
- Who does the work. The Function can be code, a model, an Agent or a credentialed Human, and callers see no difference.
- When it ships. A Verb can be published before any Function exists. It answers with a quote, and each call counts toward the decision to build it.
- Which shape it speaks. An Interface can conform to an outside Standard, such as SCIM, with no hand-written route.