Skip to main content

​
Issuance

​
Direct issuance credential not stored (no storagePath)

Direct POST /dstorage/vcs stores an encrypted credential and returns a storagePath. Hosted POST /issue-vc performs this upload internally and returns an empty response body. Issuance typically completes in ~1–4 seconds.
  • If POST /dstorage/vcs did not return a storagePath, retry with exponential backoff (start at 1 second, double each attempt, cap at 30 seconds).
  • Check DStorage endpoint configuration and that your Partner JWT is valid.
  • Do not rebuild and re-issue on every transient failure — retry the store step with the same encrypted payload fields.

​
Issuance returns 400

  • Verify holderDid, schemaId, expiresAt, data, iv, authTag, encryptedKey, and externalId are all present and correctly typed.
  • Ensure the credential data matches the schema definition exactly. Extra fields or wrong types will be rejected.
  • Check the response body for a specific error message.

​
Issuance returns 409

This usually means:
  • User consent rejected: The user has previously declined credentials from your partner account. Contact the user or wait for them to re-consent.
  • Duplicate credential: A credential already exists for this user + schema combination. Dedupe by recipient email + program ID, and revoke the existing credential before reissuing if the data changed.

​
Credential not visible to user after issuance

  • For direct issuance, confirm POST /dstorage/vcs returned a storagePath. For hosted issuance, confirm POST /issue-vc succeeded and inspect the issuer’s issuance record for its DStorage result.
  • For server-side issuance, newly created users see issued credentials when they first log in. They may be prompted to accept or reject credentials.
  • Verify via initialize-user request body contains the intended recipient’s email; direct-issuance Partner JWTs do not carry the recipient email.

​
Verification

​
Verification returns “no matching credential”

  • The user may not have a credential matching the verification program’s schema. Check that:
    • The credential was issued using the correct issuance program.
    • The credential has not been revoked.
    • The verification program’s schema matches the issuance program’s schema.

​
Verification fails with “proof invalid”

  • The credential may have been tampered with, or the issuer signature may not match.
  • If the credential was recently issued, ensure the store step returned a storagePath before attempting verification.
  • Check that the credential has not expired or been revoked.

​
User declines verification

  • The SDK prompts users for consent before presenting a credential. If the user declines, the verification result will indicate failure.
  • Your app should handle this gracefully — show a message explaining why the credential is needed and offer to retry.

​
Schema issues

​
”Schema not found” error

  • Verify the schema exists in the Developer Dashboard (Issuer > Schemas).
  • Ensure the credentialId (Issuance Program ID) references a published program, not a draft.

​
Schema mismatch between issuance and verification

  • If a verification program rejects credentials that were successfully issued, the issuance and verification programs may reference different schema versions.
  • Check both programs in the Developer Dashboard and ensure they point to the same schema.

​
CAK-specific issues

​
Encrypted data not decrypting for verifier

  • Verify the user has granted consent in the SDK UI.
  • Ensure the verification program has CAK required enabled.
  • Check that the issuer’s CAK callback URL is correctly configured and returning 200 responses.
See Privacy & Compliance for the full CAK framework.