Skip to main content

Reference: APIs

Overview

The EDC stack exposes several APIs for different purposes and audiences. All administration APIs are designed for machine clients (UI backends, automation tools), not direct human interaction.

Authentication: All APIs (except Observability) use OAuth2 client_credentials flow. Tokens carry role and participant_context_id claims for access control.

Control Plane APIs

Management API

The primary API for managing assets, policies, contracts, and transfers.

Exposed byConnector (Control Plane)
Content typeJSON-LD
AuthenticationOAuth2 (participant, provisioner)
Base path/api/management/v3/

Key resource endpoints:

ResourcePathOperations
Assets/assetsCreate, read, update, delete data assets
Policy Definitions/policydefinitionsDefine access and contract policies
Contract Definitions/contractdefinitionsCombine assets with policies into offers
Catalog/catalog/requestQuery another participant's catalog
Contract Negotiations/contractnegotiationsInitiate and monitor negotiations
Contract Agreements/contractagreementsView established agreements
Transfer Processes/transferprocessesInitiate, monitor, and manage transfers
EDRs/edrsManage Endpoint Data References

Documentation: EDC Management API

Federated Catalog API

Query the aggregated federated catalog of data offerings.

Exposed byControl Plane (optional component)
Content typeJSON
AuthenticationOAuth2 (participant)
EndpointMethodDescription
/federatedcatalogPOSTQuery with filter criteria

Identity Hub APIs

Identity API

Manage DIDs, key pairs, and verifiable credentials.

Exposed byIdentity Hub
Content typeJSON
AuthenticationOAuth2 (participant, provisioner)

Key resource endpoints:

ResourcePathOperations
DIDs/participants/{id}/didsCreate, list, manage DIDs
Key Pairs/participants/{id}/keypairsCreate, rotate, revoke keys
Credentials/participants/{id}/credentialsStore, list, manage VCs

Documentation: EDC Identity Hub

Issuer Admin API

Manage credential issuance workflows (for organizations operating an issuer service).

Exposed byIssuer Service
Content typeJSON-LD
AuthenticationOAuth2 (provisioner)
ResourcePathOperations
Holders/holdersManage credential holders
Attestations/attestationsDefine credential attestation types
Credential Definitions/credentialdefinitionsConfigure credential schemas

Observability API

Health and readiness endpoints for monitoring.

Exposed byAll components
Content typeJSON
AuthenticationNone
EndpointMethodDescription
/healthGETComponent health status
/readinessGETReadiness probe
/livenessGETLiveness probe

Access Control Model

Roles

RoleScopeIntended Client
adminFull access to all resourcesEmergency and initial setup only
provisionerCreate/manage participant contextsCFM automation, onboarding workflows
participantManage own scoped resourcesPortal UI backend, sharing applications

Key Claims

ClaimPurpose
roleAuthorization level (admin, provisioner, participant)
participant_context_idIdentifies the participant context; the security unit
scopeGranular access (e.g., management-api:read, identity-api:write)

Token Retrieval

curl -X POST "$TOKEN_URL" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&client_id=...&client_secret=..."

Best Practices

  • Keep client_id separate from participant_context_id — rotate independently
  • Use scoped tokens with least privilege
  • Separate Vault access credentials from API access credentials
  • Use role=admin only for emergencies; use role=provisioner for automation