Issue on Behalf flips this. Your backend server issues a credential directly to a user’s AIR Account without requiring any action from the user at the time of issuance. The user doesn’t need to be in a session, open a wallet, or interact with any UI.
This enables zero-friction, invisible credential issuance for use cases like:
- Issuing a KYC credential the moment a user passes identity verification
- Issuing an attendance credential when a venue scan detects a fan’s check-in
- Issuing a subscriber tier credential at the end of each billing cycle
- Issuing a loyalty credential triggered by a purchase event
The user simply benefits from the credential next time they interact with a verifier.
Feature Activation RequiredIssue on Behalf must be enabled for your partner account before use. Enable it in the Developer Dashboard (Accounts → Issuer → Advanced). When to Use It vs. Standard Issuance
| Scenario | Use Standard Issuance | Use Issue on Behalf |
|---|
| User initiates credential claim themselves | Yes | No |
| Credential is triggered by a backend event | No | Yes |
| User is actively logged in at issuance time | Yes | Either |
| User is offline / not in session | No | Yes |
| Zero-friction UX is a requirement | No | Yes |
| KYC completion triggers credential | No | Yes |
| Attendance / purchase / billing events | No | Yes |
| User explicitly clicks “Claim Credential” | Yes | No |
How It Works
- A backend event fires — KYC passed, purchase confirmed, check-in scanned.
- Your server retrieves the target user’s email and signs a Partner JWT.
- Your server calls the Issue on Behalf API endpoint.
- AIR Kit verifies the JWT and queues the credential for on-chain processing.
- Issuance is asynchronous — your server polls a status endpoint until the credential is confirmed on-chain.
- The user presents the credential later at any verifier; no action needed at issuance time.
In step 2, the email claim must be the individual target recipient’s AIR Account email — the person who should receive this specific credential. It is the routing key that determines which account the credential lands in. Never reuse a partner, service, admin, or static email, and never reuse one email across multiple recipients: every credential signed with that email will be issued to that one account.
Prerequisites
Before using Issue on Behalf you need:
- Feature activation — Enable Issue on Behalf for your partner account in the Developer Dashboard (Accounts → General).
- Partner ID and Issuer DID — From the Developer Dashboard (Accounts → General).
- Issuance program — A published credential program in the dashboard (Issuer → Programs).
- JWKS endpoint — A public URL serving your RSA public key for JWT verification. See Partner Authentication.
- User email — The email address of the AIR Account receiving the credential.
Auth
Issue on Behalf authenticates via a Partner JWT attached to each request. The JWT must include the target user’s email as a signed claim. For full setup, key generation, and examples see Partner Authentication.
Per-recipient email (common mistake)
Each Issue on Behalf call routes the credential to the AIR Account that matches the email claim in the Partner JWT. Because that email is the routing key, a single reused email sends every credential to the same account — for example, signing of JWTs with one email issues all of those credentials to that one account instead of to your individual users.
Always sign each JWT with the email of the specific user who should receive the credential.
Safeguards:
- Resolve the recipient’s email from the triggering backend event; never hardcode it.
- Never use a partner, service, admin, or otherwise static/shared email as the
email claim.
- Dedupe issuance by recipient email + program ID before calling the API, so an event replay or loop can’t fan out to the wrong account.
Next Steps
