API Maker

The backend engine for the AI era

RolesEpisode 26 5:15 10 chapters October 2026

Role-Based Access and Row Ownership: Users See Only Their Own Data

Groups decide which APIs a caller may use; which rows are theirs is the other half. Give the customers of Calm Home access to their own orders and nothing else: roles as groups, a pre-hook that scopes rows with $and, rules that fail closed, g.req.auth, and a hook for one application only.

In the playlists The complete course Security & access

Chapters

What you will learn

  • Roles as groups
  • Which APIs, then which rows
  • A pre-hook on orders: the row scope
  • $and, never a spread, and fail closed
  • What g.req.auth holds
  • A hook for one application, and the best practices
In the docsHandle role based permissions
Transcript709 words · click a time to play from there

Intro

Groups decide which APIs a caller may use. Which rows are theirs is the other half. In this video, customers of Calm Home who read their own orders, and nothing else.

Authorization bugs, the usual way

The usual bugs : change an id in the address, and read somebody else's order, an admin endpoint left open, roles written as if statements in every handler, and code from an AI assistant that forgets the check. With API Maker, a role is a set of groups, one hook scopes every read of a table, a hook can target one application, and the Security Report reads the rules and the hooks.

In this video : roles as groups, a customer who reads every order, the row scope, what g.req.auth holds, a hook for one application, and the best practices.

Roles as groups

A role screen is a list of checkboxes. In API Maker, each checkbox is a small group. A person's row holds their groups, in a column the auth provider names : a role is that list. A call passes when the groups of the application and the groups of the person both grant the API. Giving someone a role is an update of one column, no new sign-in.

A customer who reads every order

The orders of MySQL ask for the token of a customer. API Testing, MySQL, sales, orders, Get all. As Diya, a customer. Send : the orders of customer twelve, of customer twenty five, all one hundred and eighty of them. Her token is valid, and her groups grant Get all. Groups decide which APIs. Which rows belong to her is the job of a pre-hook, on the table, so every API of it is covered, today and tomorrow.

The row scope

Instance API, MySQL, sales. The pre-hooks of orders. Add Hook, Row scope - orders, and its code. Calls made by your own code are trusted and pass. The customer behind the person token, from g.req.auth. No customer, four hundred and one. Their id is added to the filter with $and, never with a spread : what the caller asks for is kept, and the owner is added on top. Any API the hook does not scope is refused : it fails closed.

Save. The same call : two orders, both hers, customer two. Now a query. Its body, the orders of customer five. Send : nothing. Her id was added with $and : no filter can widen what she reads.

What g.req.auth holds

Every hook and custom API gets the identities API Maker already checked. authAMUser : the application, from x-am-authorization. authAMDB : the person, the row of customers they signed in with. Nothing to parse, nothing to verify : and never send the password column back.

A hook for one application

A hook can also target one application. The post-hooks of orders, Add Hook, Status in words. Groups : Shop app. It runs only for API users in that group. The Code tab : it adds the status in words to each order, in g.res.output. Save. In API Testing, the orders, as Diya. Through the API user Default, the status stays a code : PAID. Through the shop app, the same orders say "Paid, being packed".

Different behaviour per application, and no if in the code.

The best practices

Keep token access by default ; publish reads through a narrow custom API. One API user per application, small groups, no broad flags, and a locked down Default before production. A person token on every table that belongs to persons, and a row scope hook on it. Never expose the users table through the generic APIs, hash its passwords and never select them. A four oh one means sign in again ; a four oh three means a missing grant.

Built on standards

Access lives in groups and hooks, not in handlers. The Security Report reads them, hooks written by AI assistants included, and flags a spread merge, a missing stamp or an API that slips past : video twenty seven. And every rule is a file in Git, reviewed like code.

Recap

To sum up. A role is a set of groups. Groups say which APIs ; a pre-hook says which rows. $and, never a spread, and fail closed. g.req.auth holds the application and the person. A hook can target one application. Next : the APIs Security Report. API Maker. Build faster, spend smarter, deliver better.