Packages
SDK Reference
Dashboard-first admin API client for Banata Auth.
@banata-auth/sdk is the dashboard-first Banata package.
It is a remote HTTP client for Banata auth endpoints. It does not talk to your database directly and it does not require self-hosting.
Start by creating a project and a project-scoped API key in the Banata dashboard. The SDK is the app-side client for that dashboard-managed project.
bash
npm install @banata-auth/sdkInitialization
ts
import { BanataAuth } from "@banata-auth/sdk";
const banata = new BanataAuth({
apiKey: process.env.BANATA_AUTH_API_KEY!,
baseUrl: process.env.BANATA_AUTH_BASE_URL!,
});BanataAuthOptions
| Option | Type | Required | Description |
|---|---|---|---|
apiKey | string | Yes | API key used for bearer auth |
baseUrl | string | Yes in practice | Base URL for Banata auth HTTP endpoints |
timeout | number | No | Request timeout in milliseconds |
retries | number | No | Retries for 5xx and 429 responses |
projectId | string | No | Legacy override for self-hosted or partially migrated setups. Managed Banata resolves project scope from the API key. |
environmentId | string | No | Default environment scope |
What The SDK Is For
Use the SDK when your app needs to manage Banata remotely:
- users
- organizations
- SSO
- directory sync
- webhooks
- RBAC
- projects
- vault secrets
- audit logs
This is the package that should feel closest to WorkOS.
Example
ts
import { BanataAuth } from "@banata-auth/sdk";
const banata = new BanataAuth({
apiKey: process.env.BANATA_AUTH_API_KEY!,
baseUrl: process.env.BANATA_AUTH_BASE_URL!,
});
const users = await banata.users.listUsers({ limit: 20 });
const webhook = await banata.webhooks.createEndpoint({
url: "https://example.com/api/webhooks",
eventTypes: ["user.created"],
});
const role = await banata.rbac.createRole({
name: "HR Admin",
slug: "hr_admin",
permissions: ["employee.read", "employee.manage", "leave.approve"],
});
await banata.rbac.updateRole({
id: role.id,
permissions: ["employee.read", "employee.manage", "leave.approve", "payroll.read"],
});RBAC Workflow
For RBAC, the SDK now supports the complete custom-role flow:
- Create permission slugs with
banata.rbac.createPermission(...) - Create a role with an initial
permissionsarray, or create it empty - Update that role later with
banata.rbac.updateRole({ id, permissions: [...] }) - Assign the role slug to an organization member with
banata.rbac.assignRole(...) - Check access with
banata.rbac.checkPermission(...)orcheckPermissions(...)
This matches the dashboard flow on /authorization/roles and /authorization/permissions.
Resource Groups
| Property | Purpose |
|---|---|
users / userManagement | User CRUD, sessions, banning, impersonation |
organizations / orgs | Organizations, members, invitations |
sso | Enterprise SSO connections |
directories / directorySync | SCIM providers, users, and groups |
webhooks | Webhook endpoints and signature verification |
rbac | Roles and permission checks |
projects | Project lifecycle and scoping |
vault | Secret storage |
auditLogs | Audit events |
events | Event stream access |
emails | Email and template operations |
domains | Domain verification |
portal | Portal link generation |
apiKeys | API key lifecycle |
Error Handling
SDK responses throw typed errors from @banata-auth/shared:
ts
import { AuthenticationError, NotFoundError } from "@banata-auth/shared";
try {
await banata.users.getUser("usr_123");
} catch (error) {
if (error instanceof AuthenticationError) {
console.error("Invalid API key");
}
if (error instanceof NotFoundError) {
console.error("User not found");
}
}Positioning
- Use
@banata-auth/sdkfor the public, dashboard-first integration story. - Create the project and issue the API key in the dashboard first. The SDK then operates inside that API key's project scope.
- Use
@banata-auth/convexonly when you intentionally want the self-hosted runtime.