Skip to main content
AIR Kit connects your application to AIR services and Moca Chain. It exposes Account Services for authentication and wallet operations and Credential Services for orchestrating issuance and verification. Your issuer backend owns credential authorization, source data, signing, encryption, and storage.

​
System overview

The SDK manages user interaction and calls AIR APIs. AIR routes issuance requests to the registered issuer backend. The issuer backend owns authorization, source data, credential creation and signing, encryption, and storage. Credential storage and on-chain proof verification are separate operations. See Account Services for login and wallet details.

​
Issuance modes

​
On-demand issuance flow (user-initiated)

Your app calls issueCredential() with the issuance program/schema context and an optional identifier. This is the client-side entry point: the SDK ensures AIR login, discovers available credentials, obtains the user’s confirmation, and requests issuance through AIR. The issuance program identifies the configured flow; the schema defines the credential’s data structure. They are distinct identifiers. The sequence below describes the orchestration, rather than an SDK parameter signature. The /v2/issuer/{partnerId}/… routes are AIR proxy endpoints, addressed by your Partner ID. AIR forwards them to the POST /available-vc and POST /issue-vc routes on your own issuer service, which use a different host and the x-api-key header. available-vc discovers credentials and returns encrypted previews. It does not issue a credential. The SDK calls issue-vc only after the user confirms. The issuer backend remains responsible for authorization, data retrieval, VC generation and signing, encryption, and storage; issueCredential() orchestrates these steps without creating or signing the VC itself.

​
Credential verification flow

The SDK loads the verification program and ensures the user is logged in to AIR. It discovers matching credentials through AIR, fetches and decrypts the selected credential, and displays the requested data for consent. After the user agrees, the SDK records consent and generates the verifiable presentation and any required proof.
1

Start verification

The partner app calls verifyCredential() with a verification program. The SDK loads the program and ensures the holder is logged in to AIR.
2

Find a matching credential

The SDK requests matching credential metadata and dStorage paths. If no credential exists, the SDK can start the accepted issuer’s on-demand issuance flow, including user confirmation.
3

Decrypt and review

The SDK fetches the encrypted credential, decrypts it on the holder’s device, and shows the requested claims.
4

Get consent and create the presentation

The user consents to verification and sharing. The SDK records consent, generates the verifiable presentation, and creates any proof required by the program.
5

Verify and return the result

The SDK runs the configured verification mode and returns the result and applicable presentation or proof material to the partner app.
If the user declines consent, the flow stops before generating or sharing the presentation. If no matching credential can be issued, verification cannot proceed with that credential.

​
Off-chain and on-chain verification

The verification program selects the mode. Both paths use the credential discovery, decryption, and consent steps above. Using dStorage or anchoring issuer state does not, by itself, mean that verification runs on-chain. The verification mode describes where the proof is checked. The app uses the returned outcome to decide whether to grant access.

​
Direct issuance and pre-issue flow

Use Direct Issuance when a backend event or batch job should issue a credential without requiring the user to be present. The issuer backend resolves the recipient’s holder DID and public key, authorizes issuance, retrieves the source data, then builds, signs, encrypts, and stores the VC. The user claims the credential when they log in to AIR. Pre-issue uses Direct Issuance to prepare credentials ahead of that login and claim step.
1

Trigger issuance

A backend event or batch job starts the flow, such as a completed KYC check, purchase, or check-in.
2

Resolve the recipient

The issuer backend uses the AIR API to resolve or create the recipient’s holder DID and public key. No active user session is required.
3

Create and store the credential

The issuer authorizes issuance, retrieves source data, creates and signs the VC, encrypts it to the holder, and stores the encrypted envelope in dStorage.
4

Claim later

The user logs in to AIR later and claims the credential. Pre-issue follows this same Direct Issuance path, ahead of the user’s login.

​
Integrating with existing systems

Your issuer backend can connect to loyalty platforms, KYC providers, ticketing systems, and payment processors. Those systems can trigger Direct Issuance, while the SDK supports user-present issuance, later claims, and verification. See the vertical integration guides for examples.

​
Service independence and login requirements

Choose the service capabilities your app needs. An AIR login is required for the user-present credential flows below; it does not imply that your app must also integrate wallet operations, gas sponsorship, or other Account Services features.

​
Next steps

Quick Setup

Install and initialize the SDK in minutes.

Solutions by vertical

Business overview and developer guide for Loyalty, Identity, Fintech, Gaming, Ticketing, Telco, and Advertising.

Quickstart: Issue Credentials

Step-by-step credential issuance walkthrough.

Direct Issuance and Pre-issue

Issue without an active user session; users claim credentials when they log in.