> ## Documentation Index
> Fetch the complete documentation index at: https://docs.air3.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Direct issuance

> How direct issuance works: a backend event issues an AIR credential without the user present.

Direct issuance lets the issuer issue from its own backend, with no user session and no screen. The user does not need to open AIR or confirm anything; the credential is in their AIR Account the next time they use it.

Typical triggers:

* A user passes a KYC check.
* A purchase is confirmed or a subscription renews.
* A venue scan records an attendance.
* A loyalty tier changes.

## The flow

```mermaid theme={null}
sequenceDiagram
    participant Event as Backend event
    participant Issuer as Issuer service
    participant AIR
    participant DS as DStorage

    Event->>Issuer: Issue a credential for this email
    Issuer->>AIR: Who is this user?
    AIR-->>Issuer: User's DID and public keys
    Issuer->>Issuer: Build, sign, encrypt
    Issuer->>AIR: Store encrypted credential
    AIR->>DS: Save ciphertext
    DS-->>Issuer: Storage reference
```

## Step by step

**1. A backend event triggers issuance**

The issuer's own servers call the issuer service's admin endpoint, protected by an admin key that never leaves the issuer's infrastructure.

**2. AIR identifies the user**

The issuer sends AIR the recipient's email inside a signed Partner JWT. AIR returns the user's DID, encryption key, and signing key. If the user has no AIR Account yet, AIR creates one.

**3. The issuer builds the credential**

The same build, bind, sign, and encrypt steps as on-demand issuance. Because AIR keeps every user's public keys, the credential is bound to the user even though they are offline.

**4. The credential is stored**

The encrypted credential is saved in DStorage. The user can present it to any AIR verifier from then on.

## Things to know

* The email must be the individual recipient's own address, never a shared or service address.
* If AIR cannot return the user's DID or encryption key, the issuer must not issue.
* Avoid duplicates: deduplicate by recipient and program, and revoke the old credential before issuing a changed one.

For implementation details, see [Direct issuance](https://docs.air3.com/products/identity/issuing-credentials#direct-issuance) and the [Issuance API reference](https://docs.air3.com/api-reference/issuance-api.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.