Anatomy of an API
An API is a published promise of Verbs on Nouns, compiled from one declaration into seven parts and served to Customers under the Startup's own name.
An API on StartupBuilder is a published promise: these Verbs on these Nouns, for these callers, on these terms. Every part compiles from one declaration, and StartupBuilder keeps the same promise to its own callers.
Exploded view
Leaseline declares a Lease Noun and sells it from one Product file, products/:
products/pro.mdx and the records it names. Change the declaration, and every part follows on the next merge.Read as text
- Routes, one per Verb: api.leaseline.app/leases, from Nouns and Verbs.
- SDK, CLI and MCP server: npm install leaseline, pip install leaseline; leaseline.app/mcp, from Verbs.
- Webhooks: Lease.renewed, signed with Leaseline-Signature, from the Events of each Verb.
- Tenants and keys: One Tenant per Customer, each with test and live keys, from Customers.
- Developer tools in the Portal: leaseline.app/portal, from a keyed Offer.
- Limits, Meter and Price: portfolio, $99 a month, API access, from the Offer.
- Reference docs: leaseline.app/docs, with llms.txt, from Nouns, Verbs and errors.
- Errors that name the fix: leaseline.app/errors/…, from the error catalog.
- Status page: leaseline.app/status, from a Monitor on each Interface.
- Versions: /v1, /v2; each Tenant pinned, from breaking Changes.
- Test environment: Test records, no money moved, from the latest merged Change.
- Changelog: By email, feed or webhook, from every merged Change.
Seven parts, one declaration
| 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, each reaching one Tenant |
| 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. Routes, OpenAPI, packages, errors, docs, the Portal tools and the changelog derive, and every record behind them lives in the Database.
Two planes
Every Startup's API serves two kinds of caller through the same Verbs and records. They differ in address, scope and name.
| The builder plane | The customer plane | |
|---|---|---|
| Who calls | The Startup's Workers, tests and previews | Its Customers and their Agents |
| Address | https: | https:, also https: |
| Packages | startup-builder | leaseline |
| Key variable | STARTUP_BUILDER_API_KEY | LEASELINE_API_KEY |
| Scope | Every Verb its Role grants, across the Startup | One Tenant, within its Offer |
curl "https: //api.leaseline.app/ leases? limit= 20" \
-H "Authorization: Bearer $LEASELINE_API_KEY"The Publication holds every name the customer plane shows, and the registry refuses one whose fields name the platform.
StartupBuilder is built the same way
StartupBuilder is the Product of startups.studio, which runs as a Startup like any other. Its API at api.sb, its SDK, CLI and MCP server compile through the same projection as every Startup's.
| StartupBuilder gives founders | 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 packages | Packages named for the Startup |
No route is written by hand, and a tool the platform keeps for itself is a defect.
What stays a choice
- 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 price, and each call counts toward building it.
- Which shape it speaks. An Interface can also speak a Standard, such as SCIM. Customize an API covers each choice.