***

title: "Permissions"
metaTitle: "Permissions and Authorization in Vendure"
metaDescription: "How Vendure permissions work: CRUD permissions per entity, special permissions, built-in permission groups, deny-by-default authorization, and custom permissions for plugins."
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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](/current/core/core-concepts/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](/current/core/core-concepts/roles/) — how permissions are grouped into roles
* [User Management](/current/core/core-concepts/user-management/) — the relationship between users and permissions
* [Custom permissions guide](/current/core/developer-guide/custom-permissions/) — implementing custom permissions in plugins