Resource Types

Resource types represent the categories of objects in your application that need authorization. When you create a resource type like "Document", "Project", or "Workspace", you establish the vocabulary your permission model is built on — tying access control to specific kinds of objects rather than broad system-wide actions.

Resource types work hand-in-hand with Roles & Permissions. Resource types define what can be protected, and permissions define who can do what to them.

The Slug Convention

Every resource type has a slug — a short, lowercase identifier that becomes the prefix in your permission strings:

{slug}:{action}

For example, a resource type with slug document produces permissions like:

document:read
document:write
document:delete
document:share

This makes your permissions self-documenting. When you see project:manage in a role definition, you immediately know it controls management access to projects.

Creating Resource Types in the Dashboard

The fastest way to set up resource types is through your Banata Auth dashboard.

1. Open your project in the dashboard
2. Navigate to Authorization > Resource Types in the sidebar
3. Click Create resource type
4. Enter a Name (e.g., "Document") — the slug is auto-generated from the name
5. Optionally customize the Slug (must be unique, lowercase, hyphenated)
6. Optionally add a Description to help your team understand what this type represents
7. Click Create

Auto-Generated Slugs

When you type a name, the dashboard automatically generates a slug by converting to lowercase and replacing spaces and special characters with hyphens.

You can always customize the slug before saving. Once created, slugs cannot be changed — you would need to delete and recreate the resource type.

Managing via SDK or API

You can also manage resource types programmatically using the Banata Auth SDK or REST API.

List All Resource Types

import { banataAuth } from "./your-auth-client";
 
const resourceTypes = await banataAuth.resourceTypes.list();
// Returns an array of resource types sorted by creation date

Or via the REST API:

curl -X POST https://your-app.com/api/auth/banata/config/resource-types/list \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

Create a Resource Type

const newType = await banataAuth.resourceTypes.create({
  name: "Workspace",
  slug: "workspace",
  description: "Top-level container for projects and documents",
});

Or via the REST API:

curl -X POST https://your-app.com/api/auth/banata/config/resource-types/create \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Workspace",
    "slug": "workspace",
    "description": "Top-level container for projects and documents"
  }'

Slugs must be unique. If you try to create a resource type with a slug that already exists, you will receive a 409 Conflict error.

Delete a Resource Type

await banataAuth.resourceTypes.delete({ id: "resource-type-id" });

Important: Deleting a resource type does not automatically remove permissions that reference its slug. Make sure to update any roles that use permissions with the deleted slug.

Connecting Resource Types to Permissions

Resource types are the foundation of your permission model. Here is how you build from resource types to runtime authorization checks.

Step 1: Define Your Resource Types

Start by identifying the core objects in your application that need access control.

document, project, workspace, billing

Step 2: Define Actions for Each Resource

Decide what users can do with each resource type.

read, write, delete, share, manage

Step 3: Create Permission Strings

Combine resource type slugs with actions to form permission strings.

document:read    document:write    document:delete    document:share
project:read     project:write     project:delete     project:manage
workspace:read   workspace:manage
billing:view     billing:manage

Step 4: Assign Permissions to Roles

Group permissions into roles that match your application's access levels.

Owner:     document:*, project:*, workspace:*, billing:*
Admin:     document:*, project:*, workspace:manage
Editor:    document:read, document:write, project:read, project:write
Viewer:    document:read, project:read

Step 5: Check Permissions at Runtime

Use the SDK to verify access in your application code.

const canEdit = await banataAuth.rbac.checkPermission({
  userId: "usr_01HXYZ...",
  permission: { resource: "document", action: "write" },
  organizationId: "org_01HXYZ...",
});
 
if (!canEdit) {
  throw new Error("You don't have permission to edit this document.");
}

See Roles & Permissions for the complete permission checking reference.

Common Patterns

Here are resource type setups that work well for different types of applications.

B2B SaaS

Developer Tool

Content Platform

Best Practices

1. Use singular nouns — Use document, not documents. The slug represents a type, not a collection.
2. Keep slugs short — Slugs appear in every permission string. doc is fine; documentation-file-resource is not.
3. Be consistent with formatting — If you use kebab-case for multi-word slugs, stick with it everywhere. The auto-generator handles this for you.
4. Start broad, refine later — Begin with a few core resource types that cover your main objects. You can always add more as your authorization needs grow.
5. Document your mapping — Keep a reference of which resource types map to which objects in your application. This helps new team members understand the permission model quickly.

Troubleshooting

"A resource type with this slug already exists"

Slugs must be unique across your project. Either choose a different slug or delete the existing resource type first if it is no longer needed.

Resource types not appearing in the dashboard

Make sure you are signed in with an account that has admin access. Resource type management requires admin-level authentication.

Deleted resource type still referenced in permissions

Deleting a resource type does not cascade to permission or role definitions. After deleting a resource type, review your roles and remove any permissions that used the deleted slug. Otherwise, those permission strings will still exist but will not match any resource type.

Next Steps

• Roles & Permissions — Assign permissions to roles using your resource type slugs
• Organizations — Set up multi-tenant workspaces where authorization is applied
• Auth Configuration — Configure your project's authentication and authorization behavior