Handle Role Based Permissions

Sooner or later every business application grows this screen. Modules down the left, operations across the top, a checkbox wherever the two meet.

---

Drawing the grid is a morning's work. Deciding what the backend should do when somebody ticks a box is what eats the rest of the sprint.

---

Two gates, and you need both

Every authenticated request in API Maker gets checked twice, and the two checks answer different questions.

	Question	Answered by	Enforced by
Gate 1 — API gate	May this caller call this endpoint at all?	The caller's groups	API Maker, before your code runs
Gate 2 — Row gate	Of the rows this endpoint can reach, which ones are this person's?	A pre-hook that injects the user's id into the filter	Your hook, before the query runs

Drop either one and you have left a hole:

• With only gate 1, PURCHASE_INVOICE_VIEW is allowed to call get-by-id, so anyone in that group can walk ids and read the whole company's invoices.
• With only gate 2, someone who can see just their own rows can still call remove-by-id and delete them.

The rest of this page sets both up for a Purchase Invoice module.

---

How authorization works in API Maker

Two identities ride along on every request, in two separate headers. People mix them up constantly, so it is worth being precise about which is which.

Header	Identity	Where it comes from	Read it with
x-am-authorization	The API user — which application	An API user created in API Maker	g.req.auth.authAMUser
x-am-user-authorization	The database user — which person	A row in your own users table	g.req.auth.authAMDB

Groups hang off the API user and grants hang off the groups. When a request arrives, API Maker walks down this chain and stops at the first level that allows it:

instance  →  database  →  collection  →  supported API  →  field

Custom APIs, System APIs and WebSocket events do not cascade. They are flat lists: either the group names them or it does not.

Worth memorising, because it saves a lot of wasted debugging: 401 means the token is missing, malformed or expired. 403 means the token is fine and no group grants that API. If you are seeing 403s, go and fix the group. Do not log the user out, and do not send them back to the login screen.

---

One group per checkbox

This is the part people push back on, so let me make the case for it.

Do not create a group called Accountant. Job titles are combinations, and combinations breed. The week HR invents "Junior Accountant, South Region" you are back in the console building another group, working out which APIs it needs, and hoping you remembered all of them.

Make each group the size of one checkbox instead. A job title then becomes nothing more than a list.

Screen	API Maker group
Purchase › Purchase Invoices › View	PURCHASE_INVOICE_VIEW
Purchase › Purchase Invoices › Create	PURCHASE_INVOICE_CREATE
Purchase › Purchase Invoices › Edit	PURCHASE_INVOICE_EDIT
Purchase › Purchase Invoices › Delete	PURCHASE_INVOICE_DELETE
Purchase › Purchase Invoices › Export	PURCHASE_INVOICE_EXPORT
Purchase › Purchase Invoices › Confirm	PURCHASE_INVOICE_CONFIRM
Purchase › Debit Notes › View	DEBIT_NOTE_VIEW
Purchase › Parcel Entry › View	PARCEL_ENTRY_VIEW

Small groups combine. Accountant is just PURCHASE_INVOICE_VIEW,PURCHASE_INVOICE_CREATE,DEBIT_NOTE_VIEW. That new job title is another list of the same groups, and nobody has to build anything.

You will want one deliberately coarser group per module, for supervisors:

Group	Meaning
PURCHASE_INVOICE_VIEW_ALL	Same APIs as PURCHASE_INVOICE_VIEW, but exempt from row scoping. A manager or auditor sees the whole company's invoices

That exemption is configuration rather than code. You gate the row-scoping hook with groupNames and it never runs for that group at all.

---

Step 1 — Grant the group exactly what it needs

Open APIs Security › API group permission, add PURCHASE_INVOICE_VIEW, and then tick almost nothing.

Going back to the screenshot at the top of the page, the View checkbox on Purchase Invoices needs exactly two grants:

Category	Granted
Instance API	erp_mongo › erp_db › purchase_invoices › SCHEMA_GET_BY_ID
Custom API	purchase-invoice-print

Everything else stays off, SCHEMA_GET_ALL and SCHEMA_POST_QUERY included. A detail screen opens one invoice at a time, so it has no business calling an API that hands back all of them. The list screen gets its own group for that.

The full set for the Purchase Invoice module:

Group	Instance APIs granted	Custom APIs granted
PURCHASE_INVOICE_VIEW	SCHEMA_GET_BY_ID	purchase-invoice-print
PURCHASE_INVOICE_LIST	SCHEMA_GET_ALL	—
PURCHASE_INVOICE_CREATE	SCHEMA_POST_BULK_INSERT	—
PURCHASE_INVOICE_EDIT	SCHEMA_PUT_UPDATE_BY_ID	—
PURCHASE_INVOICE_DELETE	SCHEMA_DEL_DELETE_BY_ID	—
PURCHASE_INVOICE_EXPORT	SCHEMA_GET_ALL_STREAM	purchase-invoice-export-xlsx
PURCHASE_INVOICE_CONFIRM	—	purchase-invoice-confirm

PURCHASE_INVOICE_CONFIRM is worth a second look. Confirming an invoice is not CRUD: it checks stock, posts ledger entries and locks the document. So it is a Custom API, and a group can grant one Custom API and nothing besides. The checkbox on screen still lines up with exactly one group.

Never switch the broad flags on for an application group. allCollections does not only grant what exists today, it grants whatever you add next month and next year too. That is how a salaries table ends up readable by a group nobody has looked at in two years.

Field level: hiding columns inside a row

Groups control individual fields as well. Anything a group cannot read gets stripped out of the response, deep-populated documents included. That last part is the one people forget.

{
    "fields": {
        "erp_mongo": {
            "erp_db": {
                "purchase_invoices": {
                    "landed_cost":       { "allowRead": false, "allowWrite": false },
                    "supplier_margin":   { "allowRead": false, "allowWrite": false },
                    "invoice_total":     { "allowRead": true,  "allowWrite": false }
                }
            }
        }
    }
}

PURCHASE_INVOICE_VIEW can now open an invoice without ever learning what the company paid for the goods.

---

Step 2 — You do not create groups or users in API Maker at runtime

This one trips up almost everyone arriving from another stack.

There is no "create group" API to call when you onboard a customer, no API user per employee, and no nightly job pushing your permission tables into API Maker's.

You write the groups once, in the console, and they go into Git along with everything else. Handing someone a role at runtime is an UPDATE on a column in your own table, which the admin screen you were already building can do.

Add a groups column to your users table

import { ISchemaType, EType, ISchemaProperty, IPropertyValidation } from 'types';

let schema: ISchemaType = {
    _id: EType.objectId,
    user_name: <ISchemaProperty>{
        __type: EType.string,
        validations: <IPropertyValidation>{ required: true }
    },
    password: <ISchemaProperty>{
        __type: EType.string,
        validations: <IPropertyValidation>{ required: true },
        conversions: { hashing: true }
    },
    passwordChangedAt: <ISchemaProperty>{ __type: EType.number },
    department: <ISchemaProperty>{ __type: EType.string },
    is_active: <ISchemaProperty>{ __type: EType.boolean },

    // 👇 the whole role model, in one column
    groups: <ISchemaProperty>{ __type: EType.string }
};

module.exports = { schema };

Rows look like this:

_id	user_name	groups
101	nikita	PURCHASE_INVOICE_VIEW
102	rakesh	PURCHASE_INVOICE_VIEW,PURCHASE_INVOICE_CREATE
103	meera	PURCHASE_INVOICE_VIEW_ALL,DEBIT_NOTE_VIEW
104	root	*

* is shorthand for every group the API user has. Keep it for your own internal service account.

Point API Maker at that column

Set groupsColumn in the default secret, or override it per database, collection or API.

import * as T from 'types';

authTokenInfo: <T.IAuthTokenInfo[]>[
    {
        authTokenType: T.EAuthTokenType.AM_DB,
        authTokenAMDB: {
            instance: 'erp_mongo',
            database: 'erp_db',
            collection: 'erp_users',

            usernameColumn: 'user_name',
            passwordColumn: 'password',

            // A password change invalidates every token issued before it.
            // Without this the password itself is embedded in the JWT.
            passwordChangedAtColumn: 'passwordChangedAt',

            // 👇 API Maker reads this column and resolves the grants itself
            groupsColumn: 'groups',

            // Columns embedded in the token — available as g.req.auth.authAMDB
            select: {
                _id: 1,
                user_name: 1,
                department: 1,
                groups: 1
            }
        }
    }
]

That is the whole wiring. From here on:

• The user logs in, and API Maker reads groups off their row.
• Access becomes the union of those groups' grants.
• Change the column, and the next token the user gets carries the new permissions.

Keep _id in select. The hook in the next step needs it to work out who owns a row, and anything you leave out of select is not in the token. You do not need to read group membership yourself. API Maker pulls that from groupsColumn and enforces it for you.

The same groupsColumn field turns up on the Google, AWS Cognito and Azure AD configurations, under groupsDataSource. Swap your own login screen for single sign-on later and the groups half of this does not change.

---

Step 3 — Log in and mint both tokens

One public Custom API, and it is the only place an API user password should ever show up. It hands the client both headers in a single round trip.

import * as T from 'types';
import * as db from 'db-interfaces';

const INSTANCE = 'erp_mongo';
const DATABASE = 'erp_db';
const USERS = 'erp_users';

async function main(g: T.IAMGlobal) {
    const userName = g.req.body.user_name;
    const password = g.req.body.password;

    if (!userName || !password) {
        g.res.statusCode = T.EStatusCode.BAD_REQUEST;
        throw new Error('user_name and password are required.');
    }

    const user: db.erp_mongo.erp_db.IErpUsers = await g.sys.db.getById({
        instance: INSTANCE, database: DATABASE, collection: USERS,
        primaryKey: 'user_name',
        id: userName,

        // 👇 Ask for the columns this API uses, and nothing else.
        //    The password column is never one of them.
        select: '_id,user_name,department,groups,is_active'
    });

    if (!user || user.is_active !== true) throw new Error('Invalid credentials.');

    // The API user password lives in the secret, never in code and never in the frontend.
    const apiUserPassword = await g.sys.system.getSecret('common.apiUserPasswords.erp_app');

    const tokens = await g.sys.system.getToken([
        {
            authTokenType: T.EAuthTokenType.AM,
            authTokenAM: { u: 'erp_app', p: apiUserPassword }
        },
        {
            authTokenType: T.EAuthTokenType.AM_DB,
            authTokenAMDB: {
                instance: INSTANCE, database: DATABASE, collection: USERS,
                usernameColumn: 'user_name', passwordColumn: 'password',
                u: userName, p: password
            }
        }
    ]);

    return {
        amToken: tokens[0],      // → send as x-am-authorization
        amDbToken: tokens[1],    // → send as x-am-user-authorization
        user: { _id: user._id, user_name: user.user_name, groups: user.groups }
    };
};
module.exports = main;

select earns its keep there. Leave it out and the lookup drags the whole row into your sandbox, password hash and all, where it can end up in a log line or an error payload without anyone meaning it to. getToken checks the credentials against that same table on its own, so this code never has a reason to hold the hash. Pass a comma-separated list of the columns you want, or -password to drop just that one.

Sending groups back lets the frontend grey out buttons the user cannot use. That is a usability thing, nothing more. The server has already made the real decision, and it makes it again on every call.

---

Step 4 — Row level security with a database level pre-hook

Groups answered "can rakesh call get-by-id on purchase_invoices?". They cannot answer "is PI-1042 rakesh's invoice?", because that is a fact about the data rather than about configuration. Pre-hooks handle the second question.

Pick the scope

Pre-hooks attach at four scopes and run outermost first. Post-hooks run the same chain in reverse.

pre  :  instance  →  database  →  collection  →  api
post :  api  →  collection  →  database  →  instance

Scope	Applies to
Instance	Every API on every collection in every database of that instance
Database	Every API on every collection in that database
Collection	Every API on that collection
API	Just that one endpoint

Put row scoping at the database scope. One hook then covers purchase_invoices, debit_notes, parcel_entries, and whatever collection somebody adds next quarter without mentioning it. That last case is the one that kills the per-endpoint if.

Attach it under Instances → erp_mongo → erp_db → Pre-hooks.

What a pre-hook can change, per API

Worth knowing, because the generated APIs do not all keep their filter in the same place. By the time your hook runs, find has already been parsed into a plain object, so mutating it changes the query.

API	Where the filter lives	How to scope it
SCHEMA_GET_ALL, SCHEMA_GET_ALL_STREAM	g.req.query.find	merge the owner into find
SCHEMA_POST_QUERY, SCHEMA_POST_QUERY_STREAM, SCHEMA_POST_QUERY_DELETE, SCHEMA_UPDATE_MANY, SCHEMA_POST_DISTINCT_QUERY, SCHEMA_ARRAY_OPERATIONS	g.req.body.find	merge the owner into find
SCHEMA_GET_BY_ID, SCHEMA_PUT_UPDATE_BY_ID, SCHEMA_PUT_REPLACE_BY_ID, SCHEMA_DEL_DELETE_BY_ID	g.req.query.find, ANDed onto the primary key	merge the owner into find
SCHEMA_POST_BULK_INSERT, SCHEMA_MASTER_SAVE	g.req.body	stamp the owner server-side
SCHEMA_POST_AGGREGATE, SCHEMA_POST_COUNT, SCHEMA_GET_DISTINCT	a pipeline / a raw query object	cannot be scoped generically, so do not grant them

The third row catches people out. get-by-id and its write siblings take an id in the URL and the caller has no way to send a find of their own, but the engine still folds whatever your hook leaves on g.req.query.find into the filter it builds around the primary key:

const findQuery = {
    [primaryKey]: _id,
    ...(sandboxReq?.query?.find || {}),   // ← your hook's filter
};

That is findOneById in MongodbOps. generateQueryGetById, generateUpdateQuery and generateDeleteQuery in CommonSqlUtils do the same for the SQL engines. One filter therefore scopes every row-driven API, so you do not have to load the row and compare owners yourself. You should not, either, since it costs a database round trip on every call.

You also get the better failure mode without asking for it. A row that is not yours never matches, so the response comes back empty rather than 403, and there is nothing for an attacker to distinguish between "no such id" and "not your id".

The database level pre-hook

import * as T from 'types';

// ── Which collections are owned by a user, and by which column ──────────────
// A collection that is not in this map is not row-scoped at all.
const OWNER_COLUMN = new Map<string, string>([
    ['purchase_invoices', 'created_by'],
    ['debit_notes', 'created_by'],
    ['parcel_entries', 'entered_by']
]);

// ── apiId → where that API carries its filter ──────────────
// One O(1) lookup per request instead of scanning four arrays.
const SCOPE_BY_API = new Map<string, string>([
    // API Maker ANDs g.req.query.find onto the primary key for the *-by-id APIs,
    // so one filter covers the list, the single read, and the writes alike.
    ['SCHEMA_GET_ALL', 'QUERY_FIND'],
    ['SCHEMA_GET_ALL_STREAM', 'QUERY_FIND'],
    ['SCHEMA_GET_BY_ID', 'QUERY_FIND'],
    ['SCHEMA_PUT_UPDATE_BY_ID', 'QUERY_FIND'],
    ['SCHEMA_PUT_REPLACE_BY_ID', 'QUERY_FIND'],
    ['SCHEMA_DEL_DELETE_BY_ID', 'QUERY_FIND'],

    ['SCHEMA_POST_QUERY', 'BODY_FIND'],
    ['SCHEMA_POST_QUERY_STREAM', 'BODY_FIND'],
    ['SCHEMA_POST_QUERY_DELETE', 'BODY_FIND'],
    ['SCHEMA_UPDATE_MANY', 'BODY_FIND'],
    ['SCHEMA_POST_DISTINCT_QUERY', 'BODY_FIND'],
    ['SCHEMA_ARRAY_OPERATIONS', 'BODY_FIND'],

    ['SCHEMA_POST_BULK_INSERT', 'STAMP_OWNER']
]);

async function main(g: T.IAMGlobal) {

    // 1. Only scope real HTTP traffic. Custom APIs, events and schedulers calling
    //    g.sys.db run under their own rules.
    if (!g.req.isApiRequestFromUser) return;

    const collection = g.req.params['collection'];
    const ownerColumn = OWNER_COLUMN.get(collection);
    if (!ownerColumn) return;                     // not a user-owned collection

    // 2. Which person is acting? Not the application — the person.
    //    API Maker has already rejected the request if the user token is missing.
    const userId = g.req.auth.authAMDB._id;
    const scope = { [ownerColumn]: userId };

    // MERGE, never replace. $and keeps whatever the caller asked for and adds ours
    // on top, so a caller can never widen the scope by sending its own created_by.
    const merge = (existing) => (existing && Object.keys(existing).length
        ? { $and: [existing, scope] }
        : scope);

    // 3. One lookup decides where the filter goes.
    switch (SCOPE_BY_API.get(g.req.reqInfo?.apiInfo?.id)) {

        // get-all, get-by-id, update-by-id, replace-by-id, remove-by-id.
        // A row that is not yours is simply never matched — no extra round-trip,
        // and no 404-vs-403 difference for an attacker to probe.
        case 'QUERY_FIND':
            g.req.query.find = merge(g.req.query.find);
            return;

        case 'BODY_FIND':
            g.req.body.find = merge(g.req.body.find);
            return;

        // Inserts: stamp the owner on the server. Never trust the body.
        case 'STAMP_OWNER': {
            const rows = Array.isArray(g.req.body) ? g.req.body : [g.req.body];
            for (const row of rows) row[ownerColumn] = userId;
            return;
        }

        // Fail closed. Aggregate, count and distinct cannot be scoped generically,
        // so if one of them is ever granted by mistake, it stops here.
        default:
            g.res.statusCode = T.EStatusCode.FORBIDDEN;
            throw new Error('This API is not available for row-scoped users.');
    }
};
module.exports = main;

A few details in there are easy to skim past.

The isApiRequestFromUser guard lets internal calls through untouched. Custom APIs, events and schedulers reaching the collection via g.sys.db run under their own rules, and a scheduler rebuilding a report is not a user at all, so there is no authAMDB to scope by.

The merge uses $and rather than a spread, and that is deliberate. { ...find, created_by: userId } looks like the same thing and is not: if the caller sends find={created_by:{$ne:null}} their key survives next to yours, and which one wins comes down to operator precedence. $and applies both conditions no matter what, so the caller cannot widen the result set.

Both lookup tables are Maps. The hook runs on every single request against the database, so scanning four arrays with indexOf is work you would be paying for constantly and getting nothing back for. A Map is also the safer shape here: ownerColumn is keyed off the URL, and a plain object would happily hand back constructor or toString for a collection with one of those names, sailing straight past the if (!ownerColumn) guard.

The default branch throws rather than falling through. A hook that ends in an implicit return quietly allows every API added after it was written. This way a mis-grant turns into a support ticket instead of a breach.

And because the scope goes into the filter rather than into a check afterwards, someone else's invoice just does not match. The caller cannot tell "no such id" from "not your id", which is what you want and costs nothing to get.

A narrower version, at collection scope

That hook fires on every call to every collection in erp_db. The two Map lookups keep it cheap, but if only one collection needs scoping there is no reason to carry the table around. Move the hook down to collection scope:

import * as T from 'types';

const OWNER_COLUMN = 'created_by';

async function main(g: T.IAMGlobal) {
    if (!g.req.isApiRequestFromUser) return;

    // API Maker has already rejected the request if the user token is missing.
    const userId = g.req.auth.authAMDB._id;
    const scope = { [OWNER_COLUMN]: userId };

    // Covers get-all AND the *-by-id APIs — API Maker ANDs this onto the primary key.
    const existing = g.req.query.find;
    g.req.query.find = existing && Object.keys(existing).length
        ? { $and: [existing, scope] }
        : scope;
};
module.exports = main;

Same idea one level up. A hook at instance scope that hits the database adds that round trip to every single call against the instance. Pick the narrowest scope that still covers what you need, and keep whatever runs there fast.

Gating a hook to specific groups

Hooks can carry a groupNames list. Give it one and the hook only runs for callers who are in those groups.

Hook has groupNames?	Caller's groups intersect?	Runs?
No	—	always
Yes	Yes	yes
Yes	No	skipped
Yes	Caller has no groups	skipped

That is how you row-scope customer-facing API users while leaving an internal integration account alone, with no if inside the hook.

It is also how supervisors see everything. List only the row-scoped groups:

groupNames: ['PURCHASE_INVOICE_VIEW', 'PURCHASE_INVOICE_LIST', 'PURCHASE_INVOICE_EDIT']

A token carrying PURCHASE_INVOICE_VIEW_ALL never triggers the hook, so nothing filters its reads. Resist writing that exemption in code. API Maker already knows the caller's groups and already decides whether the hook runs. A hand-rolled if (groups.includes('...VIEW_ALL')) return; puts the same decision in a second place, and sooner or later the two drift apart.

---

Step 5 — Try to break it

Nobody should believe a permission model until they have tried to get round it. Run these.

# 1. log in — one call, both tokens
TOKENS=$(curl -s -X POST "$BASE/api/custom-api/erp/login" \
  -H 'content-type: application/json' \
  -d '{"user_name":"rakesh","password":"<password>"}')

AM=$(echo  "$TOKENS" | jq -r '.data.amToken.token')
USR=$(echo "$TOKENS" | jq -r '.data.amDbToken.token')

# 2. his own invoice → 200
curl -s -o /dev/null -w '%{http_code}\n' \
  "$BASE/api/schema/erp/erp_mongo/erp_db/purchase_invoices/get-by-id/PI-1042" \
  -H "x-am-authorization: $AM" -H "x-am-user-authorization: $USR"

# 3. somebody else's invoice → no data   (the row gate: it never matches)
curl -s "$BASE/api/schema/erp/erp_mongo/erp_db/purchase_invoices/get-by-id/PI-2001" \
  -H "x-am-authorization: $AM" -H "x-am-user-authorization: $USR" \
  | jq '.data'                                # → null, same as an id that does not exist

# 4. an API his groups never granted → 403   (the API gate)
curl -s -o /dev/null -w '%{http_code}\n' -X DELETE \
  "$BASE/api/schema/erp/erp_mongo/erp_db/purchase_invoices/PI-1042" \
  -H "x-am-authorization: $AM" -H "x-am-user-authorization: $USR"

# 5. a collection nobody granted → 403
curl -s -o /dev/null -w '%{http_code}\n' \
  "$BASE/api/schema/erp/erp_mongo/erp_db/salaries" \
  -H "x-am-authorization: $AM" -H "x-am-user-authorization: $USR"

# 6. a field the group cannot read is absent, not null
curl -s "$BASE/api/schema/erp/erp_mongo/erp_db/purchase_invoices/get-by-id/PI-1042" \
  -H "x-am-authorization: $AM" -H "x-am-user-authorization: $USR" \
  | jq '.data | has("landed_cost")'          # → false

# 7. a list call cannot be widened from the client
curl -s "$BASE/api/schema/erp/erp_mongo/erp_db/purchase_invoices?find={created_by:{\$ne:null}}" \
  -H "x-am-authorization: $AM" -H "x-am-user-authorization: $USR" \
  | jq '[.data[].created_by] | unique'        # → ["102"]

If any of them comes back wider than you expected, your grants are wider than you think they are.

Two more things that help here:

• Send x-am-meta: true and the response tells you which groups were consulted and whether each one granted access.
• Every API user gets a Swagger document covering exactly the APIs that user can reach. Diff it in CI, and a group that quietly got wider shows up as a comment on a pull request rather than as an incident six months later.

---

Putting it together

Question	Where it is answered
Which application is calling?	x-am-authorization — the API user
Which person is acting?	x-am-user-authorization — a row in your table
Which roles does that person hold?	The groups column on that row
What may those roles call?	API group permission, in API Maker, authored once
Which rows may they touch?	A database level pre-hook
Which fields may they see?	Field level access on the group

What makes this hold up over time is that none of the enforcement lives in your endpoint code. A new collection is denied until some group grants it, and a new endpoint on an existing collection picks up the database hook the moment it exists. There is nothing you have to remember to write.

---

Common mistakes

Mistake	What happens	Fix
One group per job title	Group count grows with the org chart; every new title is a fresh audit	One group per checkbox; job titles are comma-separated lists
allCollections: true on an application group	Every table you add later is instantly reachable	Allow-list collections explicitly
allSystemApis: true	Grants EXECUTE_PLAIN_QUERY and GET_SECRET	Never set it; allow-list individual system APIs if you truly need them
Merging the owner with a spread instead of $and	A crafted find can widen the result set	find = { $and: [caller, ours] }
Loading the row to compare owners on get-by-id	An extra database round-trip on every call, for a check the engine already does	Set g.req.query.find; API Maker ANDs it onto the primary key
Omitting _id from select	The hook cannot see who is calling	Keep _id in select
Checking group membership inside a hook	The same decision now lives in two places and will drift	Gate the hook with groupNames and let API Maker decide
No passwordChangedAtColumn	The password sits in the JWT, and changing it does not invalidate old tokens	Set the column and update it on every password change
Trusting created_by from the request body	A caller can create rows owned by someone else	Stamp the owner in the pre-hook
Row scoping enforced in a Custom API only	Schedulers and test cases bypass authorization entirely	Enforce at the hook, and treat a scheduler as being as privileged as your database credentials

---

Related reading

• API group permission
• API user permission
• Authorization of AM database user
• Pre-hook · Post-hook
• Global object g
• Default secret
• Single sign on authentication