Skip to main content
An ecosystem in CREDEBL is a trust framework that brings multiple organizations together under shared governance. Instead of each organization operating independently, an ecosystem allows a lead organization to define rules, invite members, and coordinate credential schema endorsement across all participants. Common use cases include national digital identity programs, industry credential consortia, and education networks where multiple institutions issue and accept each other’s credentials.

​
Ecosystem roles

Ecosystem Lead

The governing organization of the ecosystem. The Ecosystem Lead:
  • Creates the ecosystem
  • Invites other organizations to join
  • Removes members from the ecosystem
  • Updates member status (ACTIVE / INACTIVE)
  • Manages schema endorsement rules
  • Accesses the ecosystem dashboard
Only users with the Ecosystem Lead org role can perform these actions. This role is assigned when the ecosystem is created.

Ecosystem Member

An organization that has accepted an invitation to join the ecosystem. Ecosystem Members:
  • Operate under the governance rules set by the Lead
  • Issue and verify credentials within the trust framework
  • Can view their ecosystem memberships and invitation status
The Ecosystem Member org role is assigned when an organization accepts an ecosystem invitation.
The EcosystemRoles enum defines two roles: Ecosystem Lead and Ecosystem Member. The EcosystemServiceRole enum uses the values lead and member internally.

​
Creating an ecosystem

1

Prerequisites

The creating user must belong to an organization with an active agent and hold the owner role in that organization.
2

Create the ecosystem

The organization owner calls the create ecosystem endpoint:
POST /ecosystem?orgId=<orgId>
Authorization: Bearer <token>

{
  "name": "National Education Network",
  "description": "Trust framework for accredited educational institutions",
  "logoUrl": "https://example.com/logo.png"
}
The creating organization is automatically assigned the Ecosystem Lead role.
3

Configure ecosystem settings

The Ecosystem Lead can configure settings including:
  • enableEcosystem — enable or disable ecosystem features
  • autoEndorsement — automatically endorse schema transactions from members
  • participateInEcosystem — allow the lead org to also act as a member
  • multiEcosystemSupport — allow member orgs to join multiple ecosystems
These are controlled via the EcosystemConfigSettings enum.
4

Invite organizations

The Ecosystem Lead invites other organizations:
POST /ecosystem/invitation
Authorization: Bearer <token>

{
  "orgId": "<target-org-id>",
  "ecosystemId": "<ecosystem-id>"
}
Only users with the Ecosystem Lead org role can send invitations.
5

Organizations accept or reject

The invited organization’s owner reviews the invitation. They can accept or reject it:
PUT /ecosystem/invitation/status?status=accepted
Authorization: Bearer <token>

{
  "ecosystemId": "<ecosystem-id>",
  "orgId": "<org-id>"
}
The status query parameter must be either accepted or rejected.

​
Invitation and approval workflow

Ecosystem invitations follow the same state machine as organization member invitations, using the Invitation enum:
StateDescription
pendingInvitation has been sent and is awaiting a response
acceptedThe invited organization has joined the ecosystem
rejectedThe invitation was declined
Transitions are one-directional: a pending invitation can move to accepted or rejected, but accepted and rejected states are terminal.
An organization can check the status of all its ecosystem invitations — both as a Lead and as a potential Member — using GET /ecosystem/invitations?role=<role>. The InvitationViewRole enum accepts Ecosystem Lead or Ecosystem Member as the role parameter.

​
Ecosystem member status

Once an organization has joined an ecosystem, the Ecosystem Lead can change its operational status using the EcosystemOrgStatus enum:
StatusDescription
ACTIVEThe organization is an active ecosystem participant
INACTIVEThe organization has been deactivated within the ecosystem
To update status: 
PUT /ecosystem/member/status?status=INACTIVE
Authorization: Bearer <token>

{
  "ecosystemId": "<ecosystem-id>",
  "orgIds": ["<org-id-1>", "<org-id-2>"]
}

​
Ecosystem governance and schema endorsement

On permissioned Hyperledger Indy networks, writing a schema or credential definition to the ledger requires a transaction signed by an endorser. In an ecosystem context, the Ecosystem Lead typically acts as the endorser for member organizations. The EndorserTransactionType enum defines two transaction types that require endorsement:
  • schema — publishing a new credential schema
  • credential-definition — publishing a new credential definition
When autoEndorsement is enabled in the ecosystem configuration, the lead’s agent automatically signs endorsement requests from member organizations without manual approval.

​
Removing members

The Ecosystem Lead can remove one or more organizations from the ecosystem: 
DELETE /ecosystem/member
Authorization: Bearer <token>

{
  "ecosystemId": "<ecosystem-id>",
  "orgIds": ["<org-id-1>"]
}
Removed organizations lose their Ecosystem Member role and can no longer participate in the ecosystem’s governance or endorsement flows.

​
Viewing ecosystem data

EndpointRolesDescription
GET /ecosystemplatform_admin, Ecosystem Lead, Ecosystem MemberList all ecosystems accessible to the user
GET /ecosystem/:ecosystemId/org/:orgIdplatform_admin, owner, adminDashboard data for a specific ecosystem and organization
GET /ecosystem/membersEcosystem LeadAll organizations in a specific ecosystem
GET /ecosystem/invitationsownerInvitations for lead and member roles
GET /ecosystem/invitation/statusauthenticated userStatus of pending ecosystem creation invitations

Build docs developers (and LLMs) love

Get started for freeTalk to us