> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didx.co.za/llms.txt
> Use this file to discover all available pages before exploring further.

# Quickstart

> Issue your first credential in about 10 minutes.

This quickstart walks the shortest path to a credential in your wallet. You will onboard yourself as a user, sign in to the didx:me wallet, then issue a credential to that wallet from your tenant.

End state: a credential called **DEMO** in your wallet, with your name and surname inside it.

<Steps>
  <Step title="Get sandbox access">
    Sandbox credentials are handed out via Slack while we polish the self-serve flow.

    1. Join the [public DIDx Slack](https://join.slack.com/t/didx-xyz/shared_invite/zt-3wixgicbk-oLCOAjpk7HDEwv5avRFbyA).
    2. Drop a note in the relevant channel and ping **Willem** or **Robbie** to say you'd like a sandbox `clientId` and `clientSecret` for didx:me.
    3. They'll send you the credentials and confirm the sandbox base URLs.

    Exchange the `clientId` and `clientSecret` for a bearer access token using the OAuth `client_credentials` flow described on the [Authentication](/products/didx-me/getting-started/authentication) page. Every step below sends the bearer in the `Authorization` header:

    ```bash theme={null}
    -H "Authorization: Bearer <access_token>"
    ```

    Tokens are valid for five minutes. If your script takes longer, re-run the auth call.
  </Step>

  <Step title="Onboard yourself as a user">
    The Consumer Onboarding API provisions users in your tenant. For this quickstart, you'll provision yourself.

    ```bash theme={null}
    curl -X POST https://test.didxtech.com/consumer-onboarding/api/users \
      -H "Authorization: Bearer <access_token>" \
      -H "Content-Type: application/json" \
      -d '{
        "email": "you@example.com",
        "firstName": "Your first name",
        "lastName": "Your last name"
      }'
    ```

    Response (201):

    ```json theme={null}
    {
      "email": "you@example.com",
      "tempPassword": "m!mNB!zn2*Y0"
    }
    ```

    Save the `tempPassword`. You'll use it to sign in to the wallet.
  </Step>

  <Step title="Sign in to the wallet">
    Open the didx:me wallet at [https://uat.didx.co.za/me-wallet/app/login](https://uat.didx.co.za/me-wallet/app/login). It runs in any browser; for the most realistic feel, open it on your phone.

    Sign in with the email you just onboarded (first screen), then the temp password (second screen). You'll land on an empty wallet: your name in a welcome banner, with **No credentials yet** below.

    Keep this tab open.
  </Step>

  <Step title="Create a credential template">
    A template defines the shape of the credential. Define it once, then issue many credentials from it.

    ```bash theme={null}
    curl -X POST https://test.didxtech.com/me-creds/api/templates/credentials \
      -H "Authorization: Bearer <access_token>" \
      -H "Content-Type: application/json" \
      -d '{
        "credentialFormat": "sd-jwt",
        "name": "Your first didx:me credential",
        "description": "Getting Started with your first didx:me credential",
        "code": "demo",
        "attributes": {
          "name": {
            "type": "string",
            "name": "Name",
            "required": true,
            "alwaysDisclosed": false
          },
          "surname": {
            "type": "string",
            "name": "Surname",
            "required": true,
            "alwaysDisclosed": false
          }
        }
      }'
    ```

    Each attribute takes a JSON key (the field name inside the credential payload) and a few properties: `type` is the JSON type, `name` is the display label shown in the wallet, `required` controls whether issuance demands a value, and `alwaysDisclosed` controls whether the holder can withhold the attribute at presentation time. An optional `description` adds wallet-side helper text; omitted here for brevity. See [Credentials](/concepts/credentials) for the selective-disclosure model behind `alwaysDisclosed`.

    The response includes the template's `id`. Save it for the next step.

    <Note>
      The outer `name` field is the template's display name. The inner `attributes.name` defines an attribute called `name`. Different scopes; they don't collide in JSON.
    </Note>
  </Step>

  <Step title="Create an issuance">
    An issuance binds a template to a specific set of values for one credential.

    ```bash theme={null}
    curl -X POST https://test.didxtech.com/me-creds/api/credentials/issuance \
      -H "Authorization: Bearer <access_token>" \
      -H "Content-Type: application/json" \
      -d '{
        "credentialTemplateId": "<template-id-from-previous-step>",
        "attributes": {
          "name": "Your first name",
          "surname": "Your last name"
        }
      }'
    ```

    The response (201) includes the `offerUri`:

    ```json theme={null}
    {
      "data": {
        "id": "cmocw7she01un01o5j7ag5hnl",
        "status": "offered",
        "credentials": [
          {
            "id": "cmocw7shh01uo01o5ds9s835g",
            "status": "offered",
            "credentialTemplateId": "<template-id>",
            "exchange": "openid4vc",
            "format": "sd-jwt-vc",
            "revocable": true
          }
        ],
        "offerUri": "https://creds-app.test.didxtech.com/invitation?credential_offer_uri=..."
      }
    }
    ```

    The `offerUri` uses the `creds-app.test.didxtech.com` deep-link host — that's the wallet's invitation entry point, distinct from the `test.didxtech.com` API host used elsewhere.

    Save the `offerUri`.
  </Step>

  <Step title="Push the offer to your wallet">
    Send the credential offer directly to your wallet's inbox.

    ```bash theme={null}
    curl -X POST https://test.didxtech.com/me-wallet/api/orgs/credentials \
      -H "Authorization: Bearer <access_token>" \
      -H "Content-Type: application/json" \
      -d '{
        "credentialOffer": "<offerUri-from-previous-step>",
        "recipient": "you@example.com"
      }'
    ```

    A `201 Created` with `{ "data": null }` confirms the offer was delivered.
  </Step>

  <Step title="Accept the credential in the wallet">
    Switch to the wallet tab. Refresh if needed. A **Pending Credentials** section now shows a card for your **DEMO** credential.

    Tap into the card. The detail view shows the claims (Name, Surname) and credential information. Tap **Accept**.

    The credential moves from Pending to Recent. You now have a verifiable credential signed by your tenant, held in your wallet.
  </Step>
</Steps>

## What next

Once the quickstart works, common next moves:

* **Webhooks.** Your application learns about issuance lifecycle events (`offered`, `completed`, `failed`, `expired`) without polling. See [Webhooks](/products/didx-me/guides/webhooks).
* **Verify a credential.** Define a presentation template, request a presentation from a holder, validate what they share. See the [Verifier journey](/products/didx-me/guides/verifiers/verifier-journey).
* **Trust hardening.** Attach trusted entities to your presentation templates so verifiers only accept credentials from issuers you have explicitly named. See [Trust](/concepts/trust).
* **Production readiness.** Rotate certificates, set up retry policies on your webhook handler, switch from sandbox to production keys (ask in Slack when you're ready).