> 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-3/trigger-by-user-for-equs-wallet-pull-tx_code-delivery/method-2-api-+-embed-ui.md).

# Method 2: API + Embed UI

Two calls from your back end, a pre-built Holder-facing component, and your endpoint supplying the claims

The same calls as [Method 1](/docs/issuance/flow-3/trigger-by-user-for-equs-wallet-pull-tx_code-delivery/method-1-api.md), made from your back end, with the Holder-facing half of the journey - the wallet picker, the QR code, the deep link - pre-built as a component you drop into your page. The Offer carries no claim values: your Attribute Provider supplies them when the Holder accepts.

{% hint style="warning" %}
**Work in progress.** The Issuance API for this flow is still being built. The EQUS Wallet side is ready.
{% endhint %}

**Before you start** you need an [Issuer and VC Schema](/docs/issuance/configuration-issuer-and-vc-schema.md), your identity provider registered (see [Bring Your Own IdP](/docs/onboarding/bring-your-own-idp.md)), an [Attribute Provider](/docs/issuance/configuration-attribute-provider.md) endpoint, and Embed UI installed - see [Embedded UI](/docs/embedded-ui/overview.md).

### Who calls what

**Your platform credentials never reach the browser.** Both protected Issuance calls - creating the Offer and setting `tx_code` delivery - go through **your back end**, via functions you supply.

```mermaid
flowchart LR
    E["Embed UI<br/>in your page"] --> B["Your back end"] --> P["Platform<br/>Integration API"]
    P -.->|"claims, at acceptance"| B
    style E fill:#e6f4ea,stroke:#34a853
    style B fill:#e8f0fe,stroke:#4285f4
    style P fill:#fff4e5,stroke:#f9ab00
```

The dashed edge is what makes this Flow 3: the platform calls back into your Attribute Provider for the claim values, rather than holding values you pushed earlier.

### What the Holder goes through

1. **Pick a wallet.** Only an EQUS Wallet appears, because only that wallet can fetch the code.
2. **Open the wallet** - a QR code for a mobile wallet, or the web wallet in the same tab or a new one.
3. **Sign in**, if they aren't already, through your identity provider.
4. **Accept the Offer.** Nothing to read out, and no code to type.

### What you write

Two functions you pass to `issueVC`. Embed UI calls them in the browser, and each one reaches the platform through your back end.

| Function                | Embed UI calls it             | You do                                                                                                |
| ----------------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------- |
| `getCredentialOfferUri` | when the Holder starts        | Create the Offer **without `claims`**, return `{ refUri, uriId }` from `byReference` and `uriId`      |
| `deliverTxCode`         | once a wallet has been chosen | Forward `{ offerId, method: 'pull', userId }` to the delivery endpoint, return its response unchanged |

```javascript
import { issueVC } from '@equs-ai/dtk-embedded-ui'

issueVC({
  getCredentialOfferUri,   // creates a claimless Offer
  deliverTxCode,
  userInfo: { id, email },
  internalWallet: { name: 'Our Wallet', platform: ['web', 'mobile'] },
  webWalletMode: 'embedded',
  onLoading,
})
```

### Keeping the Holder on the `pull` path

`internalWallet` is what puts an EQUS Wallet in the picker, and it is the only option whose wallet can fetch the code. Leave `externalWallet` unset and `manualTxCode` at its default of `false`.

Enabling either moves the Holder onto [`email` tx\_code delivery](/docs/issuance/flow-3/trigger-by-user-for-any-wallet-email-tx_code-delivery/method-1-api.md), where on this flow **you** own code delivery - which Embed UI cannot do for you.

Set `userInfo.id` to the Holder's user ID in your IdP: the `sub` it reports when they sign in, which is also the `userId` you create the Offer with (see [Bring Your Own IdP](/docs/onboarding/bring-your-own-idp.md)). Embed UI passes it to your `deliverTxCode` as `userId`. Without it, the EQUS Wallet isn't offered.

### The platform pulls the claims

When the Holder accepts, your [Attribute Provider](/docs/issuance/configuration-attribute-provider.md) is called once, synchronously, for the claim values. They are read fresh at that moment, used to sign the credential, and discarded within the request. If the endpoint is down, that issuance fails.

### Canceling an issuance in flight

If the Holder navigates away mid-flow, `cleanUpIssueVC()` cancels the issuance: it removes Embed UI's message listeners and closes its iframe. `cleanUpEmbeddedUi` calls it for you - see [Embedded UI](/docs/embedded-ui/overview.md).

### Track the result

See [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-3/trigger-by-user-for-equs-wallet-pull-tx_code-delivery/method-2-api-+-embed-ui.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.