Verify presentation

Overview

After the user responds to the request, call this endpoint to check the state of the verification and retrieve the credential data the user shared.

For real-time applications, prefer webhooks over calling this endpoint repeatedly. Webhooks notify your application the moment a presentation transitions to verified, rejected, or expired, with no waiting and no wasted requests. See Webhooks.

Endpoint

GET $BASE_URL/me-creds/api/v1/presentations/{id}

Request

curl -X GET "$BASE_URL/me-creds/api/v1/presentations/{presentation_id}" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Replace {presentation_id} with the id returned by Create a presentation request.

Response

HTTP 200 OK

{
  "data": {
    "id": "cmbhsgi6c00cls60120oyb8tl",
    "createdAt": "2025-06-04T10:12:20.101Z",
    "updatedAt": "2025-06-04T10:12:20.101Z",
    "status": "verified",
    "error": null,
    "notice": null,
    "presentationTemplateId": "cma2nw2vd00sos601irn14wt1",
    "credentials": [
      {
        "isValid": true,
        "name": "Basic Identity",
        "type": "https://test.didxtech.com/vct/didx/basic-identity",
        "attributes": {
          "firstName": "John",
          "lastName": "Doe"
        },
        "issues": []
      }
    ],
    "expiresAt": "2025-06-04T10:27:20.088Z",
    "authorizationRequestUri": "https://creds-app.test.didxtech.com/invitation?request_uri=...",
    "authorizationRequestQrUri": "https://creds-app.test.didxtech.com/invitation?request_uri=...&qr=true"
  }
}

Status values

Status	Description
`requested`	Waiting for the user to respond
`requestRetrieved`	User resolved the request (has no related webhook)
`verified`	The user has presented their credential successfully
`failed`	The user responded but the verification failed
`expired`	The request expired before the user responded

Credential validation fields

Field	Description
`isValid`	`true` if the credential verified cryptographically and has not been tampered with
`attributes`	The verified data the user chose to share
`issues`	Array of validation issues found. Empty if the credential is valid
`issuer`	Who signed the credential, either `{ type: "did", did }` or `{ type: "x509", commonName, certificate }`. May be `null`
`trustSignals`	Array of positive trust findings. Currently `TRUSTED_ISSUER`, meaning the signer is on your trust list

Each entry in issues is typed, so you can branch on the cause rather than parsing the message:

`issues[].type`	Meaning
`EXPIRED`	The credential is past its validity window
`NOT_YET_VALID`	The credential’s validity window hasn’t begun
`REVOKED`	The issuer revoked the credential
`INVALID_CREDENTIAL`	The credential failed cryptographic checks
`UNKNOWN`	Validation failed for an unclassified reason

isValid tells you the credential is cryptographically sound. It does not tell you the issuer is one you trust. That’s what trustSignals is for. A credential can be perfectly valid and signed by someone you’ve never heard of.

Read the data within 15 minutes

The platform trims presented attributes 15 minutes after verification. Read them promptly and persist whatever your application needs, because this endpoint is not a store. After the window closes, the request still returns 200 and status stays verified, but each credential comes back stripped:

{
  "data": {
    "status": "verified",
    "notice": "Credential data is no longer available — details expire 15 minutes after verification.",
    "credentials": [
      {
        "isValid": true,
        "format": "sd-jwt-vc",
        "name": "Unknown Credential",
        "type": null,
        "issuer": null,
        "attributes": {},
        "issues": [],
        "trustSignals": []
      }
    ]
  }
}

Field	After the window
`notice`	Explains why the data is gone. `null` while data is live
`attributes`	`{}`
`name`	`"Unknown Credential"`
`type`, `issuer`	`null`
`issues`, `trustSignals`	`[]`
`isValid`, `format`	Preserved

Trimming is all-or-nothing at the presentation level. If any credential in the response has expired, the platform sets notice.

An expired read is not a verification failure, and it does not mean the issuer was untrusted. isValid stays true while trustSignals empties to [] and issuer becomes null, so code that treats “no trust signal” as “reject” will wrongly reject a presentation that verified correctly. Branch on notice before interpreting the other fields.

This is the strongest argument for webhooks. They fire the moment a presentation reaches verified, so you read the data while it’s still there instead of discovering it’s gone.

Check validity

Always check both status === "verified" and credentials[].isValid === true before trusting the presented data. The isValid field confirms that:

The credential has not been tampered with.
The issuer’s decentralised identifier (DID) is legitimate.
The credential is cryptographically authentic.

Use the attributes from the response to process the verified user data in your application, and store what you need before the 15-minute window closes.

Overview

User Onboarding

Issuance

Verification

Branding

Webhooks

Custom Templates (advanced)

Errors

Overview

Endpoint

Request

Response

Status values

Credential validation fields

Read the data within 15 minutes

Check validity

​Overview

​Endpoint

​Request

​Response

​Status values

​Credential validation fields

​Read the data within 15 minutes

​Check validity

Overview

Endpoint

Request

Response

Status values

Credential validation fields

Read the data within 15 minutes

Check validity