Navigate to "Resources" and "Create New Resource", where you will add a resource_id and actions. Resources represent entities within your application that a user might act upon, and Actions for a Resource are the valid operations for that Resource. Together these form a permission that a user would be authorized or not authorized to take.

For example, if your application has documents, you might create a ResourceID of document with create update delete and download as the Actions.

After creating your custom Resource, you can navigate to the "Roles" tab. You will see one default Role:

• stytch_user: this Role is automatically assigned to all Users, and enables basic permissions that you'd want any User of your application to have -- such as updating their own name.

You can edit the permissions associated with this Role, and can also create your own custom Roles.

When you add permissions to a Role, you will select the Resource and then can explicitly assign a subset of permissions to that Role. For example, you might give the stytch_user Role permission to take the create and update Actions on document Resources but not allow download or delete Actions.

You can also grant the Role the "wildcard" Action, which allows Users with that Role to take any defined Action on the Resource. This is helpful for situations where the Role should always have complete control over the Resource, even as new permissions are added.

Even if you are leveraging Stytch's frontend SDKs, it is critical that you add server-side authentication and authorization checks before honoring requests from your client.

Read the backend integration guide to learn how to properly authorize requests on your backend.

If you are using Stytch's frontend SDKs, follow the headless frontend integration guide to leverage Stytch's RBAC product client-side.