> 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/issuance/flow-1.md).

# Flow 1: Pre-authorized + push claims

Send claim values up front and let the platform hold them, encrypted, until the Holder collects.

You already know who should get the credential, and you already have the data - so you push it. One call carries the VC Schema version, your own user ID, and the claim values. The platform holds those values encrypted, creates an Offer, and waits. The moment the Holder collects, the values are deleted.

This is the shortest route to a working integration: nothing to host, no endpoint to build.

```mermaid
flowchart LR
    A["Your back end<br/>pushes the claims"] --> B["Platform holds them<br/>encrypted"]
    B --> C["Offer reaches<br/>the wallet"] --> D["Holder accepts,<br/>tx_code is presented"]
    D --> E["Platform signs the VC<br/>and deletes the claims"]
    E -.->|"claim values deleted"| B
    style B fill:#fce8e6,stroke:#ea4335
    style E fill:#e6f4ea,stroke:#34a853
```

### At a glance 👀

<table data-search="false"><thead><tr><th width="200"></th><th></th></tr></thead><tbody><tr><td><strong>Protocol</strong></td><td>OID4VCI pre-authorized code</td></tr><tr><td><strong>Status</strong></td><td>Fully supported</td></tr><tr><td><strong>Who starts it</strong></td><td>You, from a business event - or one of your signed-in users, on your site</td></tr><tr><td><strong>When claims are read</strong></td><td>At push time - a snapshot</td></tr><tr><td><strong>What the platform stores</strong></td><td>Claim values, plus the Holder's email when the platform emails the code. Encrypted, scoped to your Tenant, deleted on issuance or after five days</td></tr><tr><td><strong>You host</strong></td><td>Nothing</td></tr><tr><td><strong>Auto-issuance</strong></td><td>Yes</td></tr><tr><td><strong>Effort</strong></td><td>Low - one or two API calls</td></tr></tbody></table>

**Pick this flow** when you want: the fastest integration; issuance is driven by a business event with no Holder in the loop; or it's acceptable for the platform to hold claim values for up to 5 days.

**Watch out** for two things. Personal data is written to platform storage - encrypted, scoped to your Tenant, deleted on issuance or after five days, but the write does happen. And the claims are a **snapshot taken at push time**: if the underlying record changes before the Holder collects, the credential carries the older values. If either is unacceptable, look at [Flow 3](/docs/issuance/flow-3.md).

### How the `tx_code` reaches the Holder 📬

The pre-authorized code flow always requires a `tx_code` when the Offer is accepted, and how the Holder gets it decides which wallets work, what they have to do, and whether the Offer can arrive unprompted.

[Choose a Flow](/docs/issuance/choose-a-flow.md) walks through that decision across both pre-authorized flows. What follows is what each journey means here.

<table data-search="false"><thead><tr><th width="180">Journey</th><th>Auto-issuance</th><th>pull tx_code delivery</th><th>email tx_code delivery</th></tr></thead><tbody><tr><td><strong>Who the Holder is</strong></td><td>Your user, signed in to an EQUS Wallet through your IdP</td><td>Your user, signed in to an EQUS Wallet through your IdP</td><td>Anyone, with any compliant wallet</td></tr><tr><td><strong>How the code reaches them</strong></td><td>The wallet fetches it</td><td>The wallet fetches it</td><td>The platform emails it, or you deliver it</td></tr><tr><td><strong>What the Holder does</strong></td><td>Accepts the Offer</td><td>Scans or follows a link, then accepts</td><td>Scans or follows a link, accepts, then types the code</td></tr><tr><td><strong>In Pending Offers</strong></td><td>Yes</td><td>Yes</td><td>No</td></tr><tr><td><strong>You need</strong></td><td>Your IdP registered, and the Holder's email for the notification</td><td>Your IdP registered</td><td>Nothing</td></tr><tr><td><strong>Integration paths</strong></td><td>API, Operator Portal</td><td>API, Embedded UI, Operator Portal</td><td>API, Embedded UI, Operator Portal</td></tr></tbody></table>

{% hint style="info" %}
**Using** Embedded **UI?** One `issueVC` call can cover both user-triggered journeys. Enable both wallet options, and each Holder's choice of wallet decides between `pull` and `email` - see Method 2: API + Embedded UI for [`pull`](/docs/issuance/flow-1/trigger-by-user-for-equs-wallet-pull-tx_code-delivery/method-2-api-+-embed-ui.md) or [`email`](/docs/issuance/flow-1/trigger-by-user-for-any-wallet-email-tx_code-delivery/method-2-api-+-embed-ui.md).
{% endhint %}

### Pick your journey 🛣️

<table 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-wand-magic-sparkles" style="color:$primary;">:wand-magic-sparkles:</i></h3></td><td><strong>Auto-issuance</strong></td><td>The Offer arrives by itself. Nothing to scan, no code to type.</td><td><a href="/docs/issuance/flow-1/auto-issuance.md">Auto-issuance</a></td></tr><tr><td><h3><i class="fa-mobile-screen" style="color:$primary;">:mobile-screen:</i></h3></td><td><strong>Trigger by User for EQUS Wallet</strong></td><td><code>pull</code> delivery. The Holder starts from your site and the wallet fetches the code.</td><td><a href="/docs/issuance/flow-1/trigger-by-user-for-equs-wallet-pull-tx_code-delivery.md">Trigger by User for EQUS Wallet (pull tx_code delivery)</a></td></tr><tr><td><h3><i class="fa-globe" style="color:$primary;">:globe:</i></h3></td><td><strong>Trigger by User for any Wallet</strong></td><td><code>email</code> delivery. Works with any compliant wallet; the Holder types the code.</td><td><a href="/docs/issuance/flow-1/trigger-by-user-for-any-wallet-email-tx_code-delivery.md">Trigger by User for any Wallet (email tx_code delivery)</a></td></tr></tbody></table>

All three share one-time setup - see [Issuer and VC Schema](/docs/issuance/configuration-issuer-and-vc-schema.md) - and all three leave the same record afterwards, on [Issuance Results](/docs/issuance/issuance-results.md).


---

# 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/issuance/flow-1.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.