Quickstart

This quickstart walks the shortest path to a credential in your wallet. You will onboard yourself as a user, complete onboarding, then issue a credential to that wallet from your tenant. At the end you’ll have a credential called DEMO in your wallet, with your name and surname inside it.

Before you start, you need the clientId and clientSecret DIDx issued for your organisation, and the host for your environment. Both arrive through partner onboarding. There is no self-serve signup.

Export the two variables every step below expects:

export BASE_URL="https://your-environment-host"   # the host issued with your tenant
export ACCESS_TOKEN="TOKEN_FROM_THE_AUTH_CALL"  # see Authentication

Get the token with the client_credentials flow on the Authentication page. Tokens last five minutes. If you take longer, re-run the auth call and re-export.

Onboard yourself as a user

The Consumer Onboarding API provisions users in your tenant. For this quickstart, you’ll provision yourself.

curl -X POST "$BASE_URL/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):

{
  "data": {
    "email": "you@example.com",
    "tempPassword": "",
    "emailSent": true
  }
}

emailSent: true means your onboarding link is on its way. tempPassword comes back empty on this pathway. It only carries a value on the older temp-password flow.

Complete onboarding and sign in

Check the inbox for the address you just onboarded. You’ll have an onboarding email with a single-use, time-boxed link.Follow it to set your own password, verify your email, and configure strong auth. That lands you in the didx:me wallet. It runs in any browser, and opening it on your phone is closest to how holders will use it.You’ll see an empty wallet: your name in a welcome banner, with No credentials yet below. Keep this tab open.

If no email arrives, it may have expired or bounced. Resend it with POST $BASE_URL/consumer-onboarding/api/users/USERNAME/onboarding-email. See Create user account.

Create a credential preset

A preset is the published shape of the credential: its format, attributes, and disclosure rules. Publish it once, then issue many credentials against it. The platform manages the underlying template for you.

curl -X POST "$BASE_URL/me-creds/api/v1/presets/credentials/sd-jwt" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "credentialFormat": "sd-jwt",
    "code": "demo",
    "templateName": "Your first didx:me credential",
    "templateDescription": "Getting Started with your first didx:me credential",
    "templateAttributes": {
      "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, which this example omits. See Credentials for the selective-disclosure model behind alwaysDisclosed.The response includes the preset’s id, in the form YOUR_TENANT_ALIAS:demo. Save it for the next step.

templateName is the preset’s display name. The inner templateAttributes.name defines an attribute called name. They are different scopes and don’t collide in JSON.

Presets are immutable and claim their credential type exclusively across the catalogue. If demo is already taken in your tenant, pick another code, because you can’t delete and recreate one. See Credential presets.

Create an issuance

An issuance binds a preset to a specific set of values for one credential.

curl -X POST "$BASE_URL/me-creds/api/v1/issuances" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "credentials": [
      {
        "reference": "presetId:PRESET_ID_FROM_PREVIOUS_STEP",
        "attributes": {
          "name": "Your first name",
          "surname": "Your last name"
        }
      }
    ]
  }'

reference is how you name what to issue: KIND:VALUE, where kind is presetId, templateId, or credentialType. Pass more than one entry in credentials to bundle several credentials into one offer. See Issue a credential for the other reference kinds.The response (201) includes the offerUri:

{
  "data": {
    "id": "cmocw7she01un01o5j7ag5hnl",
    "status": "offered",
    "error": null,
    "credentials": [
      {
        "id": "cmocw7shh01uo01o5ds9s835g",
        "status": "offered",
        "credentialTemplateId": "cm2ytsdid009u4ke3t30aiuvc",
        "exchange": "openid4vc",
        "format": "sd-jwt-vc",
        "revocable": true
      }
    ],
    "offerUri": "https://creds-app.test.didxtech.com/invitation?credential_offer_uri=...",
    "offerQrUri": "https://creds-app.test.didxtech.com/invitation?credential_offer_uri=...&qr=true",
    "createdAt": "2025-02-20T11:27:37.051Z",
    "updatedAt": "2025-02-20T11:27:37.051Z"
  }
}

Ignore credentialTemplateId for now. The platform manages that template for you. It only matters if you later want to list everything issued from this preset; see Issuance vs credential.The offerUri points at a creds-app.* deep-link host, the wallet’s invitation entry point, which is a different host from $BASE_URL. You pass this URI along unchanged; never construct it yourself.Save the offerUri.

Push the offer to your wallet

Send the credential offer directly to your wallet. It will appear in the Pending state in your wallet.

curl -X POST "$BASE_URL/me-wallet/api/v2/orgs/credentials" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "credentialOffer": "OFFER_URI_FROM_PREVIOUS_STEP",
    "recipient": "you@example.com"
  }'

A 201 Created with { "data": null } confirms that the platform delivered the offer.

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.

What next

Once the quickstart works, here are the common next moves:

Webhooks. Your application learns about issuance lifecycle events (offered, completed, failed, expired) without polling. See Webhooks.
Verify a credential. Define a presentation template, request a presentation from a holder, validate what they share. See the Verifier journey.
Trust hardening. Attach trusted entities to your presentation templates so verifiers only accept credentials from issuers you have explicitly named. See Trust.
Production readiness. Rotate certificates and set up retry policies on your webhook handler. Talk to DIDx when you’re ready to move beyond your initial environment.

Start

Concepts

Integrate

Standards

What next

​What next

What next