Docs / Building
API builder
Define a real hosted endpoint — schema, logic and auth — when the thing you need does not justify a service.
For endpoints that never justify a repository, a pipeline and a host: a webhook receiver, an internal lookup, a prototype that has to be genuinely callable.
Building one#
- Open Build → API Builder and create an endpoint.Choose a method and a path.
- Define the request schema.Fields and types. Requests that do not match are rejected before your logic runs.
- Write the processing logic.What it does with the input and what it returns.
- Add auth if it needs it.An API key or bearer token, checked before anything else.
- Call it.It is live on its URL. There is nothing to deploy.
What it is good for#
| Case | Why here rather than a service |
|---|---|
| Webhook receiver | Accept, validate, record — no infrastructure to keep running |
| Prototype | Answers "can I actually call it?" in a way a mock cannot |
| Internal lookup | Stops the same helper being copied into three codebases |
| API over a table | The data keeps a human owner; the consumer gets an endpoint |
Where the line is#
If you can describe what it does in one sentence, and that sentence is unlikely to grow, a hosted endpoint is the right size. If describing it takes a paragraph, it wants a repository.
Publishing documentation#
- Open the collection's Docs tab and publish.Requests, schemas and examples become a page on a public URL.
- Share the link.Another team can discover the endpoint and call it correctly without asking you.
Frequently asked questions#
Can I build an API without writing a backend?
Yes, for small endpoints. Define the method, path, request schema and processing logic, and it is hosted immediately with no deployment step.
When should I use a real service instead?
When it has substantial state, needs its own database, or will grow steadily in complexity. The builder suits endpoints whose behaviour fits in a sentence.