> For the complete documentation index, see [llms.txt](https://docs.blerify.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blerify.com/introduction-to-issuance/learn/how-issuance-works.md).

# How Issuance Works

Issuing a credential is three moves: you create it, Blerify signs it, and you deliver it. This page tells the story of what happens at each move — and why the result is something a verifier will trust without ever contacting you. When you're ready to run it yourself, [Issue a W3C Credential](/introduction-to-issuance/build/issue-a-w3c-credential.md) takes over.

{% hint style="info" %}
This is the mental model. Once it clicks, the [Build](/introduction-to-issuance/build.md) guides turn it into working calls.
{% endhint %}

***

## The flow, end to end

Everything starts with your backend, which holds the data, and ends on the holder's device. In between, Blerify turns that data into something anyone can check — no callback to your servers required.

```mermaid
flowchart LR
    A[Your backend] -->|holds the data| B[Create]
    B -->|unsigned draft| C[Sign]
    C -->|organization key| D[Deliver]
    D -->|QR / link / push| E[Holder's wallet]
```

### 1 — Create

You describe the claims the holder will carry, and Blerify assembles them into an unsigned credential shaped by your project's schema. Nothing is committed yet. This draft is safe to review, correct, or throw away — it carries the status `PENDING` and has no cryptographic weight until you sign it.

### 2 — Sign

You ask Blerify to sign the draft. It signs with your organization's key and registers the credential against the Trust Registry. This is the turning point in the story: from here on the credential is tamper-evident. Change a single field and the signature breaks. And because the signature and the trust registration are self-contained, the credential's authenticity no longer depends on anyone being able to reach your servers.

### 3 — Deliver

The signed credential travels to the holder as a QR code, a deeplink, or a push notification. Their wallet checks the signature the moment it arrives and stores the credential encrypted on-device. Blerify keeps no copy — once it's in the wallet, it belongs to the holder.

***

## What the verifier sees later

The point of all this is what happens *after* delivery, when the holder presents the credential somewhere. The verifier doesn't trust your database — they trust the math. They check the signature against your organization's key in the Trust Registry, confirm the credential hasn't been revoked, and read only the fields the holder agreed to share.

That's why signing is the moment that matters: everything a verifier needs to trust the credential is baked in at signing time. [Trust & Signing](/introduction-to-issuance/learn/trust-and-signing.md) follows this thread all the way to the verifier.

***

## Two formats travel this same path

Both credential formats Blerify issues — W3C Verifiable Credentials and ISO 18013 mDocs — move through the exact create → sign → deliver flow above. What changes is how they're encoded and where their trust is anchored. If you're choosing between them, [Credential Formats](/introduction-to-issuance/learn/credential-formats.md) lays out the trade-offs.

***

## Next steps

[**Core Concepts**](/introduction-to-issuance/learn/core-concepts.md) — the pieces this flow rests on: organization, project, service account, and schema.

See also: [Credential Lifecycle](/introduction-to-issuance/learn/credential-lifecycle.md) — what happens to a credential after it's issued · [Get Started](/introduction-to-issuance/build/get-started.md) — run the flow for real.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.blerify.com/introduction-to-issuance/learn/how-issuance-works.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.