Verify a CWT credential
Verify a CWT credential by providing the encoded payload and specifying verification options.
You can provide a valid CWT credential as either an encoded string or a QR code in a PDF document or an image file.
Standard checks performed on all verification requests:
- Conformance of the string and encoded data. All string representations of CWT credentials must be prefixed with
CSC/1. - Decoded payload structure is a valid CWT credential.
- Issuer DID can be used to resolve its
did.jsondocument. - Public key from issuer's
did.jsondocument validates the proof signature, confirming the credential has not been tampered with.
Optional parameter checks:
- Credential was issued by a trusted issuer.
- Current time is after the beginning of the credential validity period.
- Current time is not after the end of the credential validity period.
- Credential has not been revoked.
Roles
Analytics Events
bearerAuthAuthorizationBearer <token>- body
payload*stringThe CWT credential to verify, represented as an encoded string.
trustedIssuers?array<string>When you include issuers' DIDs in this array, credentials will only be verified if their iss value matches one of these DIDs. You can include multiple trusted issuers, separated by commas.
assertValidFrom?booleanMATTR VII validates the credential's nbf (not before) field by default, so that credentials that have a future nbf date will not be verified. When this field is set to false, credentials can be verified even when their nbf date is in the future.
trueassertValidUntil?booleanMATTR VII validates the credential's exp (expiry) field by default, so that expired credentials will not be verified. When this field is set to false, credentials can be verified even when their exp date has passed.
truecheckRevocation?booleanMATTR VII checks the credential revocation status by default, so that revoked credentials will not be verified. When this field is set to false, credentials can be verified even when they had been revoked.
trueVerification completed
application/json- response
VerifyCompactCredentialResponse
verified*booleandecoded*CompactCredentialSignResponse
reason?Why verification failed. Present only when verified is false.
curl -X POST 'https://example.vii.au01.mattr.global/v2/credentials/compact/verify' \ -H 'Content-Type: application/json' \ -d '{ "payload": "CSC:/1/2KCE3IQEJB5DCMSLN5KWKZABE2QFQRVDAF4CIZDJMQ5HOZLCHIYDGOJUFUYTENJNGIZTOLJVGIWTCMJQFZXGO4TPNMXGS33ENZQW2ZLEJJXWQ3QH3BAFB3LISHKGQ2KBJ6Q35NXZFD6LGZ2YIAYHZAKCF7NKTIUZUTZQ3PWDBALAWVRG5XL2H4P4WFK25X3Y5X5RTN7NOZUST67KLCEFS3EPXQU5KM7VUGOPXJLQ6K5U676PMQNWRZCZ"}'{ "verified": true, "decoded": { "iss": "did:web:organization.com", "nbf": 1645743759, "exp": 1646743759, "iat": 1645743759, "jti": "6tVMmKodQNaLywW6NGA2aA", "type": "CredentialType", "property1": "...", "property2": "..." }, "reason": { "type": "PayloadInvalid", "message": "string" }}How would you rate this page?
Retrieve presentation session result GET
Retrieves the result of an online presentation session by providing the session's ID. When a holder responds to a verification request, the result indicates whether the presentation succeeded and whether the credentials were verified. The response can be a `PresentationSuccessResult` (holder completed the presentation workflow) or a `PresentationFailureResult` (holder was unable to complete the workflow). A successful presentation may include verified credentials, credential errors (requested credentials not provided), claim errors (specific claims that failed verification), or a combination of these outcomes. Your backend should validate that the returned `challenge` matches the challenge generated before starting the session to protect against session replay attacks. For OpenID4VP sessions, this endpoint returns a result only after the session's single-use response code has been exchanged. The Verifier Web SDK performs that exchange in the browser, in the cross-device modal and in `handleRedirectCallback()` on the same-device redirect, and it is otherwise a public request to `POST /v2/presentations/sessions/{sessionId}/result`. Calling this endpoint before the exchange returns `404`, even though the session completed and the result exists. Digital Credentials API sessions do not use a response code, and their results are retrievable as soon as the response has been processed. Results are short lived, currently five minutes from when the holder responds, after which this endpoint also returns `404`. Within that window the endpoint is repeatable, so retrieving a result does not consume it. Aborting an OpenID4VP session before its result is collected discards the result. For detailed information about result structures, error types, and complete examples, see the [handling verification results guide](https://learn.mattr.global/docs/verification/remote-web-verifiers/handling-verification-results).
Verify a Semantic CWT credential POST
Verify a Semantic CWT credential by providing the encoded payload and specifying verification options. You can provide a valid Semantic CWT credential as either an encoded string or a QR code in a PDF document or an image file. Standard checks performed on all verification requests: - Conformance of the string and encoded data. All string representations of CWT credentials must be prefixed with `CSC/1`. - Decoded payload CWT structure and attributes can be validated. - Remote context schema can be resolved and validate claims can be dereferenced. - Issuer DID can be used to resolve its `did.json` document. - Public key from issuer's `did.json` document validates the proof signature, confirming the credential has not been tampered with. Optional parameter checks: - Credential was issued by a trusted issuer. - Current time is after the beginning of the credential validity period. - Current time is not after the end of the credential validity period. - Credential has not been revoked.