Permissions and access

Every permission key the MLM & Affiliate addon uses, which screen and which endpoint each one guards, the two keys that do not exist, and the KYC features that gate members.

3 min readUpdated 3 August 2026permissions, roles, kyc, access control

Access to the affiliate admin is decided by the platform's normal role and permission system — see Roles and permissions for how keys, roles and the Super Admin bypass work in general. This page lists what this addon adds.

There are 14 permission keys, all prefixed affiliate. Note that the store slug is mlm and the extension is named mlm, but not one permission key contains that word.

The keys

Four access.* keys gate admin pages. Ten view/create/edit/delete.* keys gate the API.

Key	Guards
`access.affiliate`	The admin dashboard page and its data endpoint
`access.affiliate.referral`	The Referrals page and the single-referral detail page
`access.affiliate.reward`	The Rewards page
`access.affiliate.settings`	The Settings page
`view.affiliate.referral`	List referrals, read one, read a tree node
`create.affiliate.referral`	Create a referral by hand
`edit.affiliate.referral`	Update a referral, approve or reject it
`delete.affiliate.referral`	Delete one or many referrals
`view.affiliate.condition`	List conditions, read one
`create.affiliate.condition`	Create a condition
`edit.affiliate.condition`	Update a condition, enable or disable it
`view.affiliate.reward`	List rewards, read one
`create.affiliate.reward`	Create a reward by hand
`edit.affiliate.reward`	Update a reward, mark it claimed
`delete.affiliate.reward`	Delete one or many rewards

Two keys that deliberately do not exist

A delete. key for conditions. There is no delete endpoint for conditions and no permission for one. A condition is a record of what your programme paid; disable it instead. Nobody, including a Super Admin, can remove one through the product.

An access. key for the Conditions page. It carries no page-level permission file, unlike the other three admin screens. It is reachable by anyone who can open the affiliate admin at all, and the protection is on the API underneath it — the list will not load without view.affiliate.condition, and nothing can be saved without create or edit.

edit.affiliate.condition is the most expensive grant in this addon. It sets commission rates, and it is the switch that turns a competing condition on. A role with it can double what every transaction on your platform costs you, from a screen that does not gate itself.

Treat it the way you would treat a fee-setting permission, not the way you would treat a content permission.

A minimal read-only role

For someone who needs to see the programme but not change it:

access.affiliate
access.affiliate.referral
access.affiliate.reward
view.affiliate.referral
view.affiliate.reward
view.affiliate.condition

They will see the dashboard, the referral list, the reward ledger and the rates, and every write action will fail.

A support role that can work the approval queue

Add edit.affiliate.referral to the read-only set. That allows approving and rejecting, which is the whole of the daily queue, without allowing rate changes, manual rewards or deletions.

What members need

Nothing. Every member-facing screen under /affiliate is gated on being signed in, not on a permission. There is no "is an affiliate" flag and no opt-in: every registered user has a referral link and can earn.

The two things that do gate members are KYC features.

Feature key	Label in the KYC level builder	Where it is enforced
`affiliate_mlm`	Affiliate Program	The member dashboard, in the browser only
`withdraw_affiliate`	Affiliate Payouts	The claim endpoint, server-side

affiliate_mlm hides the member's dashboard behind a verification notice. It does not stop referrals being recorded and it does not stop commissions accruing, because it is a frontend check.

withdraw_affiliate is checked by the server before a reward is claimed and is the one that actually holds money back. If your compliance position is "no payouts before verification", that is the feature to require.

Both are configured per KYC level under Admin → CRM → KYC, on the level builder's feature list.

What controls the menus

Two independent conditions, both of which must be true.

The admin entry (Business Tools → Affiliate Program) requires the mlm extension to be enabled and the viewer to hold access.affiliate. A Super Admin on an install with the extension switched off still sees nothing.

The member entry (Services → Affiliate Program) requires the mlm extension to be enabled and the viewer to be signed in.

If a permissioned admin reports a missing menu, check the extension row before you check the role.

Where the enforcement actually is

Worth knowing when you are debugging an unexpected 403 or an unexpected success:

Admin API routes carry a permission in their metadata and are checked on every request.
Admin pages carry a permission.ts file, checked when the route renders — except the Conditions page, which has none.
Member API routes check only that a session exists. There is no permission layer on /api/affiliate/*.
The reward engine checks that the mlm extension is enabled before it does anything, regardless of who triggered the underlying transaction.

Related: API and data model.