Developers

Credential infrastructure that fits the application you already have.

DiligenceID is designed around an API-first service boundary for connecting issuance, presentation, verification and lifecycle events to existing digital services.

Integration model

Keep credential capability behind a clean service boundary.

The public website does not expose platform APIs or private implementation details. Integration is scoped against the selected environment and use case.

How DiligenceID fits an existing application workflowAn application calls the DiligenceID API for supported issue, verify, status and revoke capabilities. Webhook events return operational changes to the existing business workflow.EXISTING PRODUCTApplicationUSER JOURNEYBUSINESS CONTEXTPRODUCT BOUNDARYDiligenceID APIISSUEVERIFYSTATUSREVOKEEXISTING PROCESSBusiness workflowDECISIONOPERATIONAL ACTIONWEBHOOK EVENTSApplication to DiligenceID API flowThe application, API capabilities, webhook events and business workflow are stacked in reading order.EXISTING PRODUCTApplicationUSER JOURNEY · CONTEXTPRODUCT BOUNDARYDiligenceID APIISSUEVERIFYSTATUSREVOKEWEBHOOK EVENTSEXISTING PROCESSBusiness workflowDECISION · ACTION
Capability names describe the integration model without publishing or implying undocumented endpoint paths.
01 / INTEGRATE

Issue through APIs

Connect credential issuance to authoritative source systems and existing workflows.

02 / INTEGRATE

Request verification

Start presentation journeys from an application and receive a verified outcome.

03 / INTEGRATE

Receive events

Use webhook events to coordinate asynchronous issuance and verification journeys.

04 / INTEGRATE

Manage status

Connect revocation and credential-state changes to business lifecycle events.

05 / INTEGRATE

Keep your interface

Embed the journey into existing portals and applications using thin integration layers.

06 / INTEGRATE

Choose boundaries

Keep business policy separate from wallet, credential format and platform-specific concerns where practical.

Operational evidence

Integrations need an accountable event trail.

Correlation and audit context help engineering and operations teams understand which protected action occurred, who or what initiated it, and how it resolved—without turning the public website into API documentation.

Ongoing monitoring of that issuance, verification and revocation activity over time is a Vigilance concern.

Audit log showing authentication, issuer, verification, role and platform events with outcomes
Audit activity

Developer documentation

Public API documentation is being prepared.

We are not publishing invented endpoints, credentials or sample payloads before the public interface is ready. Current integration guidance is provided for approved use cases and environments.

Future documentation is expected to cover supported issuance and presentation workflows, authentication, correlation, webhook handling, idempotency, lifecycle operations and integration security.

Thin clients, SDKs and plugins are a future integration direction, not a claim of current public availability. Supported interfaces will be documented when released.

Contact the technical team

Never place platform secrets, administrative credentials or private API material in a browser application. Production integration design must define server-side trust, authentication, callback validation and data minimisation.

Put trusted evidence to work

Design the API boundary around the trust decision.

Bring your application flow, authoritative source and expected verification outcome. We can help define a thin, secure integration.