Skip to main content
As an Issuer, you own your source data and signing keys. You build the credential, sign it with issuer-controlled keys, encrypt it to the holder’s public key, and store the encrypted envelope in DStorage. AIR routes the request and stores opaque ciphertext and metadata — it never handles your plaintext data. This page covers the hosted Issuer Backend path, where AIR and the SDK call your backend to discover available credentials and trigger on-demand issuance. If you would rather run issuance from a controlled script or backend job without hosting an issuer backend, see Direct Issuance.
When to run an Issuer BackendIntegrate an Issuer Backend when you need on-demand issuance, queryable available credentials, revocation checks, or issuer-controlled data access. New issuance programs should use the BJJ_SIG_2021 signature type by default.

​
Dashboard setup

Credential services are gated. When you first sign up, the Issuer and Verifier menus (schemas, programs, and DID settings) stay hidden until your Issuer DID is registered with AIR.
  1. Create or use an AIR Dashboard account.
  2. Download air-issuer-service and generate a seed. Your signing keys — and your Issuer DID — are derived from this seed, so keep it secure.
  3. Retrieve your Issuer DID with the tool.
  4. Contact AIR with your Issuer DID. AIR registers it against your partner account; only after AIR sets your DID do the Issuer and Verifier menus (schemas and programs) become visible.
  5. Configure the remaining issuer details under Issuer → Settings:
    • Supported signature types — BJJ_SIG_2021
    • JWKS URL / key information where applicable
    • Optional user identifier type (email, phone, or partner user ID)
    • Issuer Backend URL and endpoint paths (if you run a hosted backend; leave empty for direct issuance)
  6. Select or create a schema, then create an issuance program.

​
Technical integration

See Issuance API Reference for request and response details.

​
Hosted Issuer Backend flow

Use this when you can operate a backend for on-demand issuance.

​
Step 1 — Configure the backend

Set up your issuer backend / environment with:
  • Issuer DID and signing keys
  • Schema and program configuration
  • API keys / partner auth
  • DStorage endpoint configuration
  • Issuer data source connection
  • A generated private API key, shared with AIR — AIR sends it in the x-api-key header when calling your issuer-hosted endpoints
If your Issuer Backend enables CORS, allow *.air3.com so AIR can call your available-vc and issue-vc endpoints.

​
Step 2 — Expose available-vc

Your backend exposes POST /available-vc and accepts the AIR-resolved holder identity:
  • Retrieves the user’s eligible credential data from your data source.
  • Returns { data: [...] }, with each credential subject encrypted to the holder’s pubKey.
  • Accepts optional schemaId and proofType filters.

​
Step 3 — Expose issue-vc

Your backend exposes POST /issue-vc with the same holderDID, pubKey, and userId, plus the required schemaId and optional proofType:
  • Retrieves the final user data.
  • Builds the VC and signs it with issuer-controlled keys.
  • Encrypts the VC to the user’s public key.
  • Stores the encrypted VC via DStorage.
  • Returns an empty response body after successful issuance. The issuer backend stores the DStorage response in its issuance record; it does not return the storagePath to AIR.
Both endpoints require x-api-key: <issuerBackendApiKey>. AIR resolves and supplies userId; use it—not holderDID alone—to retrieve partner-owned eligibility and claim data.

​
Step 4 — Trigger issuance

AIR / the SDK triggers issuance by calling your backend, typically from a user-initiated frontend flow. The user’s raw data never leaves your control in plaintext, and AIR stores only the encrypted envelope and metadata.

​
Compliance encryption (CAK)

When compliance encryption is enabled for your issuance program (configured in the Developer Dashboard), you can obtain a user-specific public key (cakPublicKey) to encrypt additional compliance data for regulated disclosure or threshold decryption. The key is deterministically derived from the [User – Issuer – Schema] composite identifier, so the same key is returned for the same combination.

Full CAK Issuer Guide

For Dashboard configuration, encrypting user data with the CAK public key, and implementing the callback endpoint, see the dedicated CAK Issuer Guide.

​
View issued credential records

Review the records of every credential you have issued in the Developer Dashboard under Issuer → Usage Records. Where a credential needs to be invalidated, use the Revoke function in the Dashboard.
Issued credential records on the Usage Records page

Issuer -> Usage Records in the Developer Dashboard

When operating the self-hosted issuer service, you can also query GET /admin/issuance-history and revoke by nonce with POST /admin/revoke. Issued BJJ credentials reference the public GET /credential-status/:nonce endpoint for non-revocation proofs. See the Issuance API Reference for the complete issuer-side contract.

​
Best practices for issuers

  • Only issue credentials after thorough validation of submitted evidence or claims.
  • Keep source data and signing keys under issuer control; never expose plaintext user data to AIR.
  • Minimize personally identifiable information — issue privacy-preserving credentials whenever possible.
  • Adopt open, standardized schemas to maximize compatibility across apps.
  • Implement robust expiry and revocation processes, and keep holders and verifiers informed of credential status.
  • Treat bulk imports as an operational process for large backfills, not the default integration path.

​
Next steps