> For the complete documentation index, see [llms.txt](https://docs.toolkit.equs.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.toolkit.equs.ai/docs/about-the-system/overview.md).

# Overview

Add verifiable credential issuance, verification and wallets to your product, for people, organizations and the AI agents acting on their behalf.

Hey there, builder, welcome to the EQUS Developer Toolkit! 👋

**EQUS Developer Toolkit (EQUS DTK)** lets you add digital credential journeys to your product without building the wallet, protocols, or orchestration layers yourself. If you are not familiar with verifiable credentials, you might want to read about the [Concepts](/docs/about-the-system/concepts.md) first.

Use it to run Issuance flows, request Presentations, and embed wallet experiences in your own applications. In Decentralized Identity terms, you operate the **Issuer** and **Verifier** journeys through our platform, while your users complete those journeys in the **Holder** role with the platform wallets or any compatible standards-based wallet. If your users act through AI agents or use cases involve agentic payments, those flows are supported too.

You keep control of the use case, user journey, and business logic. The platform handles the wallet infrastructure, credential exchange flows, and standards-based interoperability. 

### Actors in the platform

<figure><picture><source srcset="https://701364325-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFaucIkpW1i4WOAQC06fj%2Fuploads%2FiMYV6f2QVZV1EfLQmD56%2FEQUS_Issuance_Presentation_dark.svg?alt=media&amp;token=a7beb26e-5b7c-41b5-927d-48ed4433ea1d" media="(prefers-color-scheme: dark)"><img src="https://701364325-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFaucIkpW1i4WOAQC06fj%2Fuploads%2FA0JEmIOaGpnEcZFTMDrx%2FEQUS_Issuance_Presentation_light.svg?alt=media&amp;token=fd7d7e9e-1a56-4e38-a3e6-44940dc96088" alt=""></picture><figcaption></figcaption></figure>

There are three main actors:

* 🏢 **You:** Your organization integrates the platform and acts as Issuer and Verifier: you define use cases, configure journeys and trigger flows.
* 👤 **Users**: The people you invite into your credential journeys. They receive credentials, store them in a wallet, and present them when asked. Users take the **Holder** role.
* 🤖 **Agents:** AI agents controlled by users or your services. They can also participate in Issuance and Presentation flows. For example, an agent can act on a payment mandate through AP2.

{% hint style="info" %}
**Your Tenant** 🏠&#x20;

Your organization's isolated environment on the platform is called a **Tenant**. Your Tenant runs on shared platform infrastructure with logical isolation. A dedicated single-tenant deployment on your infrastructure is available on request. The APIs and integration model are the same either way, so this choice doesn't affect how you build.
{% endhint %}

### How it works

1. **Configure the use case:** choose the credentials, the wallet your users will use, and which systems to connect.
2. **Trigger the flow:** start Issuance or Presentation from your product, back office, or service layer.
3. **Let users complete the journey:** users receive, store, or present credentials through a supported wallet experience.

For example, you can issue employee credentials during onboarding, then request a Presentation later for access control or eligibility checks.

### Two sides of the solution

<figure><picture><source srcset="https://701364325-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFaucIkpW1i4WOAQC06fj%2Fuploads%2FUSI7Cr2hp2fVVNN0j6T1%2FEQUS_Platform_Services_dark.svg?alt=media&amp;token=e311e7de-17a7-4a10-a045-575cbf0299e4" media="(prefers-color-scheme: dark)"><img src="https://701364325-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFaucIkpW1i4WOAQC06fj%2Fuploads%2FbxMqnmShXrMEBpO0a10t%2FEQUS_Platform_Services_light.svg?alt=media&amp;token=c8fefc5f-bf05-4ae9-ac68-30a574ca4a8e" alt=""></picture><figcaption></figcaption></figure>

The platform combines an admin and integration layer for your teams with a user-facing layer for Holder journeys.

#### User-facing experiences

This side is for the people using credentials.

* **Embedded UI** brings issuance, presentation, and wallet screens into your product with minimal front-end work.
* **Mobile Wallet** gives your users a non-custodial wallet for use cases that require device-held keys.
* **Web Wallet** gives your users a platform-hosted custodial wallet that you can use standalone or embed into your own experience.

{% hint style="info" %}
The **Web Wallet** is disabled by default and is only available on request.
{% endhint %}

#### Platform APIs

This side is for the teams running the use case.

* Three APIs support the Issuer and Verifier roles. Use them to configure your environment, connect your systems, and run credential flows from your own applications.
  * **Control API:** The administrative API for configuration, platform operations, and flow setup for Issuance, Presentation, and revocation.
  * **Integration API:** The primary integration API for your back-end services to start and manage Issuance and Presentation flows.
  * **Protocol API: T**he API that exposes low-level Decentralized Identity protocol operations, metadata, and PKI-like infrastructure.
* **Web wallet API** supports custodial wallet journeys behind the user interface and can also be reused by machine agents and server-side applications.

Together, these two sides let you launch a complete Decentralized Identity experience. Your teams control the **Issuer** and **Verifier** logic. Your users complete the **Holder** journey.

### Choose your integration path&#x20;

Pick the approach that matches your product and team:

* **Use Embedded UI + API** when you want the fastest route to production with ready-made wallet and credential screens.
* **Use the API directly** when you want deeper control over orchestration, business rules, and the surrounding user experience.

### Core capabilities

Use the platform to:

* **Launch credential journeys faster** with hosted components, wallet infrastructure, and ready-to-integrate APIs.
* **Issue trusted credentials** from your own product, process, or back-office workflow as an Issuer.
* **Request and verify proofs** when a user needs to show claims, eligibility, or status as a Verifier.
* **Accept credentials from EUDI Wallets**, the European Digital Identity Wallets that EU Member States provide under eIDAS 2.0, with the [certificate-based Verifier identification](/docs/presentation/configuration/configuration-eudi-ecosystem.md) they require.
* **Support different wallet choices** with platform wallets and interoperable standards-based wallets.
* **Support Holder journeys** through wallet experiences that let users receive, store, and present credentials.
* **Let AI agents act for users** with [AP2](/docs/agentic/ap2.md) mandates that users approve in their own wallet, so an agent can prove to a merchant what it is allowed to buy.
* **Manage the full lifecycle** from Issuance to Presentation, results tracking, and revocation.

### Interoperability

You can launch with platform-provided wallets and still support a broader wallet ecosystem. If a wallet supports the required standards, it can participate in the same Issuance and Presentation journeys. You can learn more about the [Supported Standards](/docs/about-the-system/standards.md) on the dedicated page.

This lets you start with a managed experience and expand wallet choice over time without redesigning your integrations.

### Wallet choices

You can design around the wallet model that fits your audience:

* **Mobile Wallet:** Non-custodial and device-based. This is a good fit when users should control their own keys.
* **Compatible third-party wallets:** Useful when your users already have a wallet that supports the required standards. This includes the [EUDI Wallet](/docs/presentation/configuration/configuration-eudi-ecosystem.md): you can accept credentials from it once your Verifier is set up for the EUDI ecosystem.
* **Web Wallet, custodial**: Key material is held by the platform rather than the user. It suits cases where device-held keys are impractical for your audience. It is disabled by default and available on request.

These wallet options support the **Holder** role while keeping **Issuer** and **Verifier** orchestration on your side.

{% hint style="info" %}
The provided solution does not include a non-custodial Web Wallet or a custodial Mobile Wallet. These options may be available on request.
{% endhint %}

### Next steps

#### Ready to build? 🚀

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h3><i class="fa-cubes" style="color:$primary;">:cubes:</i></h3></td><td><strong>Components</strong></td><td>See the main building blocks.</td><td><a href="/docs/about-the-system/components.md">Components</a></td></tr><tr><td><h3><i class="fa-list-check" style="color:$primary;">:list-check:</i></h3></td><td><strong>Supported Standards</strong></td><td>Check wallet and protocol compatibility.</td><td><a href="/docs/about-the-system/standards.md">Supported Standards</a></td></tr></tbody></table>

#### Start building

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h3><i class="fa-file-signature" style="color:$primary;">:file-signature:</i></h3></td><td><strong>Issuance</strong></td><td>Launch your first Issuance flow.</td><td><a href="/docs/issuance/overview.md">Issuance</a></td></tr><tr><td><h3><i class="fa-user-check" style="color:$primary;">:user-check:</i></h3></td><td><strong>Presentation</strong></td><td>Launch your first Presentation flow.</td><td><a href="/docs/presentation/overview.md">Presentation</a></td></tr></tbody></table>

#### Explore wallet options

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h3><i class="fa-globe" style="color:$primary;">:globe:</i></h3></td><td><strong>Web Wallet</strong></td><td>Learn about the custodial wallet experience.</td><td><a href="/docs/wallets/web-wallet.md">Web Wallet</a></td></tr><tr><td><h3><i class="fa-mobile-screen" style="color:$primary;">:mobile-screen:</i></h3></td><td><strong>Mobile Wallet</strong></td><td>Learn about the non-custodial wallet experience.</td><td><a href="/docs/wallets/equs-wallet.md">EQUS Wallet (mobile)</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.toolkit.equs.ai/docs/about-the-system/overview.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.