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

# Flow 3: Pre-authorized + pull claims

Trigger issuance with no claim values, and let the platform pull them from your endpoint when the Holder accepts

Flow 3 is Flow 1's shape with Flow 2's privacy posture. You trigger issuance exactly as you would in Flow 1 - from a business event or one of your signed-in users on your site - but the call carries no claim values, only a VC Schema version and your own user ID. Only when the Holder actually accepts does the platform come back to your Attribute Provider and pull the data.

The result: Flow 1's trigger model and its Holder experience, auto-issuance included, without the platform ever holding anything personal.

```mermaid
flowchart LR
    A["You trigger issuance<br/>schema id + user-id only"] --> B["Platform creates the Offer<br/>and tx_code, no personal data"]
    B --> C["Holder accepts<br/>and the code is presented"]
    C --> D["Platform calls your<br/>Attribute Provider"]
    D --> E["Platform signs<br/>and returns the VC"]
    style B fill:#e6f4ea,stroke:#34a853
    style D fill:#fff4e5,stroke:#f9ab00
```

{% hint style="warning" %}
**Partially supported.** EQUS Wallet support is ready; the Issuance API is still being built. This flow is documented so you can design against it - check with us before building.
{% endhint %}

### 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>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 signing time - fresh</td></tr><tr><td><strong>What the platform stores</strong></td><td>Nothing personal</td></tr><tr><td><strong>You host</strong></td><td>An Attribute Provider endpoint</td></tr><tr><td><strong>Auto-issuance</strong></td><td>Yes</td></tr><tr><td><strong>Effort</strong></td><td>Medium - one API call, a hosted endpoint, and your own code delivery where the Holder has to type it</td></tr></tbody></table>

**Pick this flow** when you want Flow 1's trigger model and Holder experience together with the guarantee that the platform stores nothing personal, and when claim values should be read fresh at acceptance rather than snapshotted at push time.

**Watch out** for two things. You take on a **runtime dependency**: the platform calls your Attribute Provider on every acceptance, and if it's down, that issuance fails. And where the Holder has to type the code, **you own delivery** - the platform hands it to you rather than sending it, so you need a channel of your own.

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

Same three journeys as [Flow 1](/standards/issuance/flow-1.md), with one difference in the last one: on `email` delivery the code comes back to **you** to send, because the platform emailing it would mean storing a contact detail.

[Choose a Flow](/standards/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><strong>You deliver it</strong> - the platform never does</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, an Attribute Provider, and the Holder's email for the notification</td><td>Your IdP registered, and an Attribute Provider</td><td>An Attribute Provider, and a channel of your own for the code</td></tr><tr><td><strong>Integration paths</strong></td><td>API</td><td>API, Embedded UI</td><td>API, Embedded UI</td></tr></tbody></table>

There is no Operator Portal path here. The portal collects claim values in its Issue VC modal, which is Flow 1's model; on this flow the values come from your endpoint instead.

### 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; the claims are pulled when the Holder accepts.</td><td><a href="/standards/issuance/flow-3/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="/standards/issuance/flow-3/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. Any compliant wallet, with the code sent by you.</td><td><a href="/standards/issuance/flow-3/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 - [Issuer and VC Schema](/standards/issuance/configuration-issuer-and-vc-schema.md) and an [Attribute Provider](/standards/issuance/configuration-attribute-provider.md) - and all three leave the same record on [Issuance Results](/standards/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/standards/issuance/flow-3.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.