> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.adid.dev/llms.txt.
> For full documentation content, see https://docs.adid.dev/llms-full.txt.

# Receive a Credential

##### When to use

An issuer is offering you a credential. There are three delivery mechanisms supported on IDA:

1. **In-platform** — the credential is issued to your DID; you see it appear in `/credentials`.
2. **DIDComm** — the issuer sends an encrypted message to your DIDComm endpoint; you accept it from the wallet's "Pending" list.
3. **Out-of-band link** — the issuer hands you a URL; clicking it opens the platform with a confirmation dialog.

##### Before you begin

* You have shared your DID with the issuer (in-platform: you signed in; DIDComm/OOB: you sent your DID via email or QR).
* The credential is for *your* DID — verify the `credentialSubject.id` field matches.

##### Steps (in-platform delivery)

1. The issuer enters your DID in their portal and clicks **Issue**.
2. You see a notification (bell icon) on your dashboard within seconds.
3. Open `/credentials` — the new VC is at the top of the list with a **New** badge.
   4\. Click the credential to open the detail page.

##### Steps (DIDComm delivery)

1. The issuer sends a DIDComm `issue-credential` message to your DID's `DIDCommMessaging` endpoint.
2. The platform receives it via `POST /api/v1/didcomm/receive` and stores it as a pending message.
3. Open `/inbox` (or the wallet's pending tab). You see "Credential offer from did:adi:0xUniv..." with the schema name.
4. Click **Accept**. The platform sends the response, the issuer signs and returns the VC, and it lands in your `/credentials` list.

##### Steps (Out-of-band link)

1. The issuer hands you a URL like `https://adid.dev/credentials/claim?offerId=abc123`.
2. Click the URL while signed in. The portal verifies the offer is for your DID and renders an accept dialog.
3. Click **Accept**. Same outcome as DIDComm delivery.

##### Verify

The credential should appear in `GET /api/v1/credentials`:

```bash
curl https://adid.dev/api/v1/credentials \
  -H "Authorization: Bearer $ACCESS_TOKEN"
```

```json
{
  "data": [{ "id":"urn:uuid:...", "issuer":"did:adi:0xUniv...", "type":["VerifiableCredential","UniversityDegreeCredential"], "issuedAt":"..." }],
  "total": 1
}
```

##### Troubleshooting

| Symptom                                             | Cause                                | Fix                                                             |
| --------------------------------------------------- | ------------------------------------ | --------------------------------------------------------------- |
| Credential never arrives                            | Wrong DID shared with issuer         | Re-share, ask issuer to re-issue.                               |
| Credential shows in `/inbox` but not `/credentials` | Not yet accepted                     | Click **Accept** in inbox.                                      |
| Detail page shows `verified: false`                 | Schema mismatch or signature invalid | Contact issuer; check schema id against `/credentials/schemas`. |

#### 3.2.3. Viewing & Managing Your Credentials ##### When to use

Day-to-day inspection of what you hold and where it came from.

##### Before you begin

* Signed in as a holder.
* At least one credential received.

##### Steps

1. Navigate to `/credentials`.
2. Filter by:
   * **Issuer** — type-ahead search backed by the trusted issuers list.
   * **Schema** — select from a dropdown of received schema types.
   * **Status** — `active`, `revoked`, `expired`, `suspended`.
3. Click any credential row to open the detail.
4. The detail page shows:
   * **Claims** — pretty-printed.
   * **Issuer** — DID, with click-through to [Trust Explorer](#trust-explorer).
   * **Status** — live revocation check (calls [§3.2.5](#check-status) automatically).
   * **Raw VC** — collapsible JSON dump.
   * **Actions** — *Create presentation*, *Generate ZK proof*, *Delete*, *Export*.

##### API

<table>
  <tr>
    <th>cURL — list</th>

    <th>cURL — get</th>
  </tr>

  <tr>
    <td>
      ```bash
      curl "https://adid.dev/api/v1/credentials?limit=50&offset=0" \
        -H "Authorization: Bearer $ACCESS_TOKEN"
      ```
    </td>

    <td>
      ```bash
      curl "https://adid.dev/api/v1/credentials/urn:uuid:c5b7e3..." \
        -H "Authorization: Bearer $ACCESS_TOKEN"
      ```
    </td>
  </tr>
</table>

##### Verify

The list count matches the badge on the **Credentials** sidebar tile.

##### Troubleshooting

A credential that disappears from the list typically had its row deleted. Deletion is *local* (the chain anchor remains). If you need to restore, contact the issuer for a fresh copy.

#### 3.2.4. Creating a Verifiable Presentation ##### When to use

A verifier has asked you for a presentation — typically by sharing a Proof Request URL/QR (see [§5.2](#proof-request-builder)). You want to compile one or more of your VCs into a signed VP and submit it.

##### Before you begin

* The verifier's Proof Request (a Presentation Definition per DIF [Presentation Exchange v2](https://identity.foundation/presentation-exchange/spec/v2.0.0/)).
* The VCs that satisfy the request.

##### Steps

1. Open the Proof Request (URL or QR scan in the wallet).
2. The portal/wallet matches the request against your held VCs and shows you which credentials would satisfy each input descriptor.
   3\. Approve. The portal calls `POST /api/v1/presentations/create` (`vc.go:316`).
3. The API:
   * Fetches the named VCs.
   * Constructs a VP envelope.
   * Signs the VP with your DID's authentication key.
   * Returns the VP JSON.
4. The portal/wallet then submits the VP to the verifier (typically via `POST /api/v1/presentations/verify` on the verifier's side, or a callback URL specified in the Proof Request).

##### API & SDK

<table>
  <tr>
    <th>cURL</th>

    <th>TypeScript SDK</th>
  </tr>

  <tr>
    <td>
      ```bash
      curl -X POST https://adid.dev/api/v1/presentations/create \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        -H "Content-Type: application/json" \
        -d '{
          "holderDid":"did:adi:0x9a2c...",
          "credentialIds":["urn:uuid:c5b7e3..."],
          "challenge":"verifier-nonce-abc",
          "domain":"verifier.example.com"
        }'
      ```
    </td>

    <td>
      ```ts
      const vp = await client.createPresentation({
        holderDid: 'did:adi:0x9a2c...',
        credentialIds: ['urn:uuid:c5b7e3...'],
        challenge: 'verifier-nonce-abc',
        domain: 'verifier.example.com',
      });
      ```
    </td>
  </tr>
</table>

Response (truncated):

```json
{
  "verifiablePresentation": {
    "@context":["https://www.w3.org/ns/credentials/v2"],
    "type":["VerifiablePresentation"],
    "holder":"did:adi:0x9a2c...",
    "verifiableCredential":[ { ... } ],
    "proof":{ "type":"Ed25519Signature2020", "challenge":"verifier-nonce-abc", "domain":"verifier.example.com", "proofValue":"z3..." }
  }
}
```

##### Verify

The verifier's portal will show "Presentation received → verifying..." and within \~1 s display the verdict. You should see a matching record in your own `/presentations/history` (if surfaced — currently part of [§5.4 Verification History](#verification-history) for the verifier side).

##### Troubleshooting

| Code                                    | Cause                                           | Fix                                           |
| --------------------------------------- | ----------------------------------------------- | --------------------------------------------- |
| `400 NO_MATCHING_CREDENTIAL`            | None of your VCs satisfy the request            | Acquire the missing credential first.         |
| `403 NOT_HOLDER`                        | The VC's `credentialSubject.id` is not your DID | You cannot present someone else's credential. |
| `409 PRESENTATION_REJECTED_BY_VERIFIER` | Verifier policy rejected the VP                 | See response body for `reasons[]`.            |

#### 3.2.5. Checking a Credential's Revocation Status ##### When to use

You hold a credential and want to confirm it has not been revoked. The status check is also performed automatically every time you open a credential's detail page.

##### Before you begin

You have a credential ID.

##### Steps (manual)

```bash
curl https://adid.dev/api/v1/credentials/urn:uuid:c5b7e3.../status
```

(No auth needed — this endpoint is public, registered at `router.go:68`.)

Response:

```json
{
  "credentialId":"urn:uuid:c5b7e3...",
  "revoked": false,
  "statusListId":"abcd",
  "statusListIndex": 42,
  "checkedAt":"2026-04-26T12:00:00Z"
}
```

##### How it works under the hood

The handler reads the bit at the credential's `statusListIndex` from the **RevocationRegistry** contract. Bit `1` = revoked, bit `0` = active. See [§4.4.3](#status-list-mechanics) for the bitstring encoding.

##### Troubleshooting

| Code                       | Cause                                              | Fix                    |
| -------------------------- | -------------------------------------------------- | ---------------------- |
| `404 CREDENTIAL_NOT_FOUND` | Credential never existed or was deleted from index | Confirm credential ID. |
| `502 CHAIN_UNREACHABLE`    | RPC down                                           | Retry.                 |