Permissions

Permissions are the atomic units of authorization in Vendure. Every API operation is guarded by one or more permissions, and an administrator can only perform an operation if their assigned Roles include the required permission.

CRUD permissions

Most entities in Vendure are protected by a standard set of four permissions following the Create / Read / Update / Delete pattern. For example, the Product entity is guarded by:

• CreateCatalog
• ReadCatalog
• UpdateCatalog
• DeleteCatalog

These CRUD permissions are grouped by domain rather than by individual entity. The Catalog domain covers Products, ProductVariants, Collections, Facets, and Assets — so a role with ReadCatalog can read all of those entities.

Built-in permission domains

Vendure ships with permissions organized into the following domains:

• Catalog — Products, ProductVariants, Collections, Facets, FacetValues, Assets
• Customer — Customers, CustomerGroups
• Order — Orders, Fulfillments, Refunds, Payments
• Promotion — Promotions, Coupons
• Settings — Countries, Zones, TaxRates, TaxCategories, Channels, PaymentMethods, ShippingMethods, Sellers, StockLocations
• System — Global settings, Jobs, Administrator accounts, Roles, Tag, Zone members

Each domain has the full set of CRUD permissions, giving fine-grained control over what each role can access.

Special permissions

In addition to the CRUD permissions, Vendure defines several special permissions:

• SuperAdmin — bypasses all permission checks. Only the built-in SuperAdmin role carries this permission and it cannot be assigned to custom roles.
• Owner — allows a customer to access their own resources (e.g., their own orders and addresses) without needing broader read permissions.
• Public — marks operations that are accessible without any authentication, such as browsing the product catalog in the Shop API.

Deny-by-default

Vendure follows a deny-by-default authorization model. If an API operation does not have an explicit @Allow() decorator granting access via a specific permission, it is inaccessible. This ensures that new API operations are secure by default and permissions must be intentionally granted.

Custom permissions

Plugins can define their own permissions using the PermissionDefinition class. This is useful when a plugin introduces new functionality that needs its own authorization controls — for example, a reporting plugin might define ReadReports and ManageReports permissions.

Custom permissions appear alongside the built-in permissions when defining roles, allowing administrators to control access to plugin functionality in the same way they control access to core features.

Further reading

• Roles — how permissions are grouped into roles
• User Management — the relationship between users and permissions
• Custom permissions guide — implementing custom permissions in plugins