Menu Permission Catalog

Written by Rohman Beny Riyanto

GET /profile/menu returns the sidebar tree for whoever is logged in - but it's not the same tree for everyone. Some items only show up for a caller who holds a specific permission. This page explains what decides that, so you're not left guessing why a menu item is missing for one account and not another.

Why the same endpoint returns different trees

Every item in the tree can optionally be gated by a permission - a named object:action pair, like role:read. If an item is gated:

• The caller only sees it if their token's effective permissions include that exact pair.
• If it's ungated, everyone who can reach that part of the tree at all sees it (still limited to their own admin/customer area - a customer token never sees admin items regardless of gating).

A gated item that's missing from the tree isn't a bug - it means the account genuinely doesn't hold that permission. Check what the account's permissions actually are via Get User Permissions before assuming something's broken.

What permissions actually exist

A permission only works as a gate if it's a real, known pair - there's a fixed catalog of valid object:action combinations, and you can't gate a menu item on something outside it. As of this writing:

Object	Actions
role	read, create, update, delete
permission	read, assign, revoke
menu	create, update, delete
merchant	create
admin	register

The full, always-current list (with labels and grouping) is available live from Get Permission Catalog - treat the table above as a snapshot, not the source of truth.

Notice there's no entry yet for everyday business objects like order, device, payment, finance, or settings - menu items in those areas can only be scoped by which admin section they live in, not by a fine-grained permission check, until a matching permission is added to the catalog.

Who ends up holding a given permission

Two ways an account acquires a permission:

• A default baseline some sub-roles get automatically (e.g. the staff sub-role can always read the role/permission catalog, no grant needed).
• An explicit grant, made by someone with the right access through the Roles & Permissions endpoints (Grant Role Permission, Grant User Permission).

A root-level admin account (the top of a given account tree) always sees every gated item that has a real entry in the permission catalog - it doesn't need an explicit grant for anything that already exists there.

Practical example

admin-roles-permissions (the menu item that links to the Roles & Permissions page) is gated on role:read. That means:

• A root/super-admin account always sees it.
• A staff sub-role sees it too, since role:read is part of its default baseline.
• Any other account only sees it after being explicitly granted role:read.

If an account should have access to a feature but its menu item isn't showing up, that's the first thing to check: does the account actually hold the permission the item is gated on, via Get User Permissions?