Skip to main content
An organization is the primary multi-tenant unit in CREDEBL. Every operation — issuing credentials, requesting proofs, creating schemas, and managing agents — is scoped to an organization. Users can belong to multiple organizations, each with a different role.

Organization creation workflow

1

Create the organization

A user calls POST /orgs with a name, optional logo, and other metadata. The authenticated user is automatically assigned the owner role for the new organization.
2

Provision an agent

After creation, the owner provisions a dedicated or shared agent for the organization. The agent spin-up process creates a wallet and registers a DID on the chosen ledger.
3

Invite members

The owner or admin sends invitations via POST /orgs/:orgId/invitations. Each invitation specifies the invitee’s email address and their intended role.
4

Invitee accepts

The invitee receives an email and accepts the invitation. Their invitation status transitions from pendingaccepted. Rejection is also possible (rejected), and accepted and rejected states are terminal.
5

Assign or update roles

An owner or admin can update a member’s roles at any time using PUT /orgs/:orgId/user-roles/:userId.

Organization roles

CREDEBL uses role-based access control (RBAC) defined by the OrgRoles enum. Each role grants specific permissions within an organization.
RoleValueDescription
ownerownerFull control of the organization. Can manage all members, roles, agents, and credentials. Can delete the organization.
adminadminManages members and roles. Can create schemas and credential definitions. Cannot delete the organization.
issuerissuerCan issue credentials to holders and manage issuance records.
verifierverifierCan send proof requests and verify presentations.
membermemberRead-only access to organization resources (dashboard, credentials, proofs).
holderholderCan view issued credentials for the organization.
super_adminsuper_adminElevated admin privileges within the organization.
platform_adminplatform_adminPlatform-level administrator. Can register and map all organizations.
Ecosystem LeadEcosystem LeadGoverns an ecosystem. Can invite and manage ecosystem member organizations.
Ecosystem MemberEcosystem MemberParticipates in an ecosystem as a member organization.

Role capabilities in detail

Owner

  • Create, update, and delete the organization
  • Invite and remove members
  • Update member roles
  • Access organization dashboard, users, DIDs, and invitations
  • Manage agent and wallet configuration
  • Create and delete client credentials
  • Delete issuance and verification records
  • Access activity count and all platform organisations (when Ecosystem Lead)

Admin

  • Invite and remove members
  • Update member roles
  • Create schemas and credential definitions
  • Access organization dashboard, users, DIDs, and invitations
  • Update organization details

Issuer

  • Create credential offers (including OOB offers via email)
  • Upload CSV files for bulk issuance
  • Download and manage bulk issuance templates
  • Access issued credentials and file upload records
  • Fetch organization schemas and credential definitions

Verifier

  • Send proof requests to connections
  • Send out-of-band proof requests
  • Verify presented proofs
  • Access proof presentation records
  • Fetch schemas and credential definitions

Member

  • View organization dashboard
  • View schemas, credential definitions, credentials, and proofs
  • Read-only access — no issuance or verification actions

Ecosystem Lead

  • Create and manage an ecosystem
  • Invite organizations to the ecosystem
  • Remove ecosystem members
  • Update ecosystem member status (ACTIVE / INACTIVE)
  • Access all platform organizations for ecosystem management

Permissions by endpoint

Key endpoints and which roles can access them:
EndpointAllowed Roles
GET /orgs/:orgIdowner, admin, issuer, verifier, member
PUT /orgs/:orgIdowner, admin
DELETE /orgs/:orgIdowner
GET /orgs/:orgId/rolesowner, admin
POST /orgs/:orgId/invitationsowner, super_admin, admin
PUT /orgs/:orgId/user-roles/:userIdowner, admin
GET /orgs/:orgId/didsowner, admin, issuer, member
PUT /orgs/:orgId/primary-didowner, admin, issuer, verifier, member
POST /orgs/:orgId/client_credentialsowner
POST /orgs/:orgId/credentials/offerowner, admin, issuer
POST /orgs/:orgId/proofsowner, admin, verifier
POST /orgs/:orgId/proofs/:proofId/verifyowner, admin, verifier

Public vs. private organizations

Organizations can expose a public profile accessible without authentication via GET /orgs/public-profiles/:orgSlug and GET /orgs/public-profile (paginated list). Public profiles allow external parties to discover and learn about an organization without requiring membership. The private organization detail endpoint GET /orgs/:orgId requires authentication and an appropriate role within that organization.

Client credentials for machine-to-machine access

For automated or server-to-server API access, CREDEBL supports OAuth 2.0 client credentials. This allows a backend application to authenticate as an organization without a user session.

Creating client credentials

Only the organization owner can create client credentials:
POST /orgs/:orgId/client_credentials
This returns a clientId and clientSecret. Store the secret securely — it cannot be retrieved again.

Obtaining an access token

Exchange the client credentials for a bearer token:
POST /orgs/:clientId/token
Content-Type: application/json

{
  "clientId": "<client-id>",
  "clientSecret": "<client-secret>"
}
The response includes an access token and sets a session_id cookie. Use the token as a Bearer token in subsequent API calls.

Fetching existing credentials

Members with owner, admin, issuer, verifier, or member roles can retrieve the current client ID (but not the secret) via:
GET /orgs/:orgId/client_credentials
Client credentials are scoped to a single organization. Each organization has at most one client credential pair. Deleting and recreating credentials invalidates the previous secret.

Inviting members

Invitations are sent in bulk by posting an array of email addresses with their intended roles:
POST /orgs/:orgId/invitations
Authorization: Bearer <token>

{
  "invitations": [
    { "email": "[email protected]", "orgRoles": ["issuer"] },
    { "email": "[email protected]", "orgRoles": ["verifier"] }
  ]
}
Pending invitations can be listed with GET /orgs/:orgId/invitations and deleted with DELETE /orgs/:orgId/invitations/:invitationId. Only owner, super_admin, and admin roles can send invitations.

Build docs developers (and LLMs) love