Write a function, ship an API.
Write a function and publish it as an API in one step — and every table gets a REST API the moment it exists.
Create a table, get an API. No routes to write, no server to run.
For custom logic, deploy TypeScript that runs right next to your data.
The same row-level rules guard the API — no second auth layer to maintain.
An API the instant you have a table
Create a table and the endpoints to read and write it already exist — no routes to define, no server to keep running.
Read and write, ready — List, fetch, create, update — all there the moment the table is.
No server to run — Nothing to deploy or keep alive. The API is just part of the project.
Functions are your building blocks
Write a function and publish it as an API in one step. Then reuse that same function anywhere — wire it to a webhook, an MCP tool, a queue, or a schedule.
Publish in one step — Ship a function and it's a live API — nothing to host, nothing to route.
Connect it anywhere — The same function backs a webhook, an MCP endpoint, a queue, or a schedule.
Connect to anything, safely
Store the keys your functions need — for payments, email, or any outside service — encrypted and kept out of your code.
Keys stay out of your code — Add a secret once and your functions can read it — never hard-coded, never in the repo.
Reach third parties — Payments, email, an AI provider — your functions connect out with the keys kept safe.
What you'd build with it
The kind of problem APIs is there to solve.
Your iOS, Android, and web apps all read and write through the same API, so a dish favorited on one shows up on all.
Publish one function and your app has a real endpoint that takes a payment through Stripe, with the keys kept out of your code.
A function calls out to an AI provider or a shipping API and returns just what your app needs — no separate server to run.
No hand-written CRUD, no GraphQL schema to learn. Your tables are the API.
Compare shovelbase →