Skip to content
This page View Markdown Open in ChatGPT Open in Claude

How API Maker works

API Maker is a program that runs on a server. Your apps call it over the internet. It talks to your databases and runs your own code. This page shows each part once, in simple words, so the rest of the docs make sense.

In short

  • Your app calls a URL. API Maker checks who calls, runs the API, and answers in JSON.
  • Every table gets ready-made APIs. Your own logic goes in custom APIs and hooks.
  • Each app has a login : an API user. Its groups list what it may call.
  • Your code runs in sandboxes : small containers, apart from API Maker.
How API Maker Works: The Life of a Request, from Your App to Your Data11 chapters and the transcript

API Maker in one picture

API Maker in one picture : your apps → API Maker (ready-made APIs, your code, security) → your databases Your apps Website, web app Mobile app Other servers, AI agents they call URLs, with a token API Maker Ready-made APIs for every table : read, search, save, update, delete Your own code custom APIs, hooks, events, schedulers · 8 languages Security locked by default : you say which app may call what and built in : cache · logs · WebSockets · Git Your databases MongoDB · MySQL · MariaDB PostgreSQL · SQL Server Oracle · TiDB · Percona your data stays here Admin panel you build, test and watch, in your browser API Maker Launchpad a desktop app : installs API Maker on your computer or your servers

You do three things, in this order :

  1. Install it. API Maker Launchpad does it in a few clicks.
  2. Build in the admin panel. Connect a database, and its tables have APIs. Add your code where you need it.
  3. Call it from your apps. Each app gets a login and a list of what it may call.

What happens when your app calls an API

The life of a request : app → Caddy → token and groups → pre hooks → the API → post hooks → reply Your app web · mobile · server or an AI agent Caddy HTTPS ends here :443 → :38246 API Maker one process, or a cluster behind Caddy Token & groups API gate · row gate 401 · 403 if not Pre hooks your code check · change · stop The API schema · generated custom · system Post hooks your code reshape · notify Reply JSON · XML YAML · text · file Redis cache answers again in µs Your databases MongoDB · SQL · Oracle The API asks the cache first when caching is on, then the database. Sandboxed : your code runs in Docker containers, apart from API Maker. x-am-authorization 200 · 201 with data, or 400 · 401 · 403 · 404 with every error at once
  1. Your app calls a URL, for example GET /api/schema/admin/mongodb/shop/products?limit=10. It sends its token in the header x-am-authorization.
  2. API Maker checks the token. No valid token : 401. A token whose groups do not allow this API : 403.
  3. Your pre hooks run, if you wrote some. A hook can change the request : for example, keep a person to their own rows.
  4. The API runs. It reads or writes the database, or runs your function. With caching on, a read can come from the cache.
  5. Your post hooks run, if you wrote some. They can change the answer.
  6. API Maker answers : { "success": true, "statusCode": 200, "data": … }. When something is wrong, errors takes the place of data.

More : the answer · the headers · error messages.

The kinds of APIs

The API families : one base URL, one token, four HTTP families, your code in any language and the code API Maker runs for you https://api.example.com/api/… one host, one token header, every family below Schema APIs /api/schema/… 17 per table · types, rules, encryption, ids from the schema Generated APIs /api/gen/… 17 per table · schemaless, data passes as it is Custom APIs /api/custom-api/… your function, in any language, any path and method System APIs /api/system-api/… 23 ready APIs : tokens, encrypt, cache, events, indexes, checks Your code TypeScript on Node.js or Bun Python · PHP · C# · Go · Rust Java · Kotlin one g in every language Run by API Maker, not called over HTTP Events after an API hit or from your code · Schedulers on intervals and cron · WebSocket events pushed to clients Process initializers when a sandbox starts · Migration scripts on deploy · Hooks around every API · Test cases
Kind Its URL starts with What it is
Schema APIs /api/schema/ The ready-made APIs of a table. They check every write against the schema of the table : types, rules, default values.
Generated APIs /api/gen/ The same APIs, without the checks of a schema.
Custom APIs /api/custom-api/ Your own function, behind a path you choose.
System APIs /api/system-api/ Ready-made tools : tokens, encryption, the cache, indexes.

Your code can also run without a URL : hooks (before or after an API), events (after something happened), schedulers (on a timer) and WebSocket events (live messages to your apps).

In a URL, admin is the user path of the account which owns the APIs. The first account of a new installation has admin. Each developer account has a path of its own. All APIs at a glance lists every API with its URL.

Who may call what

Two tokens, two gates : the API user (which application) and the person (which rows) 1 · get the tokens The application POST …/system-api/admin/token { "u": "shop_app", "p": "…" } an API user of API Maker → x-am-authorization The person POST …/system-api/admin/token { "name": "users_tg", "u": "alice", "p": "…" } a row of your users table → x-am-user-authorization Google, Azure AD, AWS Cognito and custom providers give the person token too : x-google-authorization… 2 · call an API with both GET /api/schema/admin/shop/main/orders x-am-authorization: eyJ… x-am-user-authorization: eyJ… Public APIs (IS_PUBLIC) need no token. Token access needs the API user, and the person only when the settings name an auth provider. 401 · token missing or expired 403 · no group grants the API 3 · two gates in API Maker API gate the groups of the API user may this application call this API of this table ? which fields it may read and write 403 when no group grants it Row gate your pre hook of the rows this API reaches, which are this person's ? g.req.auth.authAMDB find = { owner: person.id } only the rows of Alice, only the fields her app may see

There are two gates.

  • The API gate : which app. Each app gets an API user : a username and a password. The app trades them for a token at the token API, then sends the token on every call. The groups of the API user list the APIs, tables and fields it may use. See API users and groups.
  • The row gate : which person. When people sign in to your app, a second token says who the person is, in x-am-user-authorization. A pre hook then keeps each person to their own rows. See sign-in of your users.

A new account starts with an API user default and a group Default, which allows everything. The password of default is kept in the default secret, at common.apiUserPasswords.default. It is empty on a new account, unless your installation sets one : type one there before you ask for a token. Before you go live, replace both : one small group per screen of your app, as Handle role based permissions shows.

Some APIs need no token at all : set their access to public (IS_PUBLIC) in their settings.

Where your code runs

Where code runs : sandboxes per account and language, and the native process API Maker one process per server, every core ; settings and schemas run here a run past its time is cut short, an error ends it sandboxes : Docker containers of each account account shop · TypeScript 1 sandbox, more while busy, up to the count account shop · Python its own runtime, packages and Dockerfile account crm · Go native process · runOnNativeProcess on the machine, beside API Maker : not isolated The trust model Containers run unprivileged, with no memory limit : a guard against faulty code more than hostile code. Separate clients : separate servers. Like the sandboxes, the native runner answers what the code asks of g.sys itself, and hands only the answer back.
  • In a sandbox, by default. A sandbox is a Docker container, apart from API Maker. Each language has its own sandboxes, and API Maker starts more of them when many calls come. A call has a time limit : 13 seconds unless you set another. See Sandbox settings.
  • On the machine, when you ask. Code marked Run on native process runs next to API Maker, without Docker. It is faster and less isolated : use it for a browser with Playwright, or the lowest delay. See native process.
  • In eight languages. TypeScript (on Node.js or Bun), Python, PHP, C#, Go, Rust, Java and Kotlin. See Languages.
  • With one object, g. Your code gets the request (g.req), the answer (g.res) and every API of API Maker (g.sys.db, g.sys.system, g.sys.cache). See the global object g.

You write the code in the admin panel, with completion of your tables and fields. Or in your own editor : the local client keeps a folder in sync, both ways.

What runs on a server

One server set up by API Maker Launchpad : the reverse proxy → systemd (API Maker : APIs, WebSockets, admin panel) → Docker (MongoDB, Redis, sandboxes) → your databases Internet apps · users Your Ubuntu server 1 vCPU · 1 GB RAM is enough to start Reverse proxy :80 · :443 (SSL) Caddy, Ferron or Pingap automatic HTTPS systemd · one program API Maker :38246 APIs · WebSockets every core of the server api_maker_be.service Admin panel :4626 · served by API Maker Docker MongoDB API Maker's own data · :38248 Redis cache · counters · :7479 Sandboxes your custom code runs here one per account and language Files /root/config : .env, the proxy, a compose file per service /root/projects/sava_api_maker · /root/logs · /root/docker-data Your databases MongoDB · MySQL · MariaDB PostgreSQL · SQL Server Oracle · TiDB · Percona on this server, or anywhere reached through the connection strings of your secret
  • API Maker : one program, kept running by systemd. It uses every core of the server.
  • A reverse proxy (Caddy, Ferron or Pingap) in front of it, for HTTPS.
  • MongoDB and Redis, in Docker. MongoDB keeps the settings and the code of API Maker. Redis keeps the cache. Your own data stays in your databases.
  • The sandboxes of your code.
  • The admin panel, served by API Maker itself.

You do not set this up by hand : Launchpad does it. For more servers, see the architectures.

What happens when you save a row

The stages of a write through a schema API, in order, from the request to 201 or 400 POST body "price": "25" "name": " Mouse " Keys not in the schema : 400 Types "25" → 25 date, objectId Clean trim, case defaults conversionFun your function, its return is kept Secure encrypt · hash with your secret Ids ObjectID, UUID auto increment Rules required, min, length, email, enum validatorFun your rule, with the whole object 201 · saved, row returned ids and defaults filled in 400 · every error at once nothing is saved Generated APIs (/api/gen) skip all of this.

A schema API checks a row before it reaches the database. It trims spaces, fixes types and fills default values, then runs the rules of the schema and your own checks. When something is wrong, you get 400 with every problem at once, and nothing is saved. See Table schema.

Everything is in Git

Your schemas, APIs, code and settings are files. The admin panel commits them to a Git repository, and another server pulls them : that is how a change ships. Secrets never go to Git. See Git integration.

On video

What Is API Maker? The Backend Engine for the AI EraThe transcript
API Maker v4: Months of Backend Work, Done in MinutesThe transcript
API Maker Admin Panel Tour: Find Any Page in Two Keystrokes12 chapters and the transcript
Next step · 2 of 7 Install API Maker Launchpad installs and starts it on your computer, in a few clicks.