Skip to main content

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.

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.
1

Get sandbox access

Sandbox credentials are handed out via Slack while we polish the self-serve flow.
  1. Join the public DIDx Slack.
  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 page. Every step below sends the bearer in the Authorization header:
-H "Authorization: Bearer <access_token>"
Tokens are valid for five minutes. If your script takes longer, re-run the auth call.
2

Onboard yourself as a user

The Consumer Onboarding API provisions users in your tenant. For this quickstart, you’ll provision yourself.
curl -X POST https://test.didxtech.com/consumer-onboarding/api/users \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "[email protected]",
    "firstName": "Your first name",
    "lastName": "Your last name"
  }'
Response (201):
{
  "data": {
    "email": "[email protected]",
    "tempPassword": "m!mNB!zn2*Y0"
  }
}
Save the tempPassword. You’ll use it to sign in to the wallet.
3

Sign in to the wallet

Open the didx:me wallet at https://test.didxtech.com/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.
4

Create a credential template

A template defines the shape of the credential. Define it once, then issue many credentials from it.
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 for the selective-disclosure model behind alwaysDisclosed.The response includes the template’s id. Save it for the next step.
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.
5

Create an issuance

An issuance binds a template to a specific set of values for one credential.
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:
{
  "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=..."
  }
}
Save the offerUri.
6

Push the offer to your wallet

Send the credential offer directly to your wallet’s inbox.
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": "[email protected]"
  }'
A 201 Created with { "data": null } confirms the offer was delivered.
7

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, 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 Verification guides.
  • 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, set up retry policies on your webhook handler, switch from sandbox to production keys (ask in Slack when you’re ready).