Keyless wallet testbed

The isolated Authbound testbed can accept issuance and verification creation without an API key. An operator must enable this mode and publish the credential definition and matching verification policy first. This guide does not indicate that a particular deployment has been activated. Use synthetic data only. Production and ordinary staging still require API keys. The server SDK requires a key when constructing its client, so use direct HTTP for this keyless flow. No tester-specific adapter or Authbound SDK is required.

Configure the test

These examples use curl and jq. Confirm the active credential definition and policy with the testbed operator. The pension profile uses the example IDs below; other profiles use the same endpoints with their own definition, claims and policy.

export AUTHBOUND_API_URL='https://testbed-api.authbound.io'
export AUTHBOUND_CREDENTIAL_DEFINITION_ID='pension-credential'
export AUTHBOUND_POLICY_ID='pol_authbound_pension_v1'

Do not send X-Authbound-Key, X-Authbound-Publishable-Key, or Authorization on either creation request. Supplied credentials are validated normally, including empty or invalid values; they do not opt into keyless access.

1. Issue a credential

This synthetic payload matches the pension definition in the SDK example. Use InTime issuance: the claims are supplied now, so no later administrative update is needed.

OFFER=$(jq -n --arg definition "$AUTHBOUND_CREDENTIAL_DEFINITION_ID" '{
  credentialDefinitionId: $definition,
  issuanceMode: "InTime",
  claims: {
    Person: {
      given_name: "Totti",
      family_name: "Aalto",
      birth_date: "1993-03-03",
      personal_administrative_number: "030393-995E"
    },
    Pension: {
      typeCode: "KAEL",
      typeName: "Kansaneläke",
      startDate: "2024-02-01"
    }
  }
}' | curl --fail-with-body --silent --show-error \
  "$AUTHBOUND_API_URL/v1/openid4vc/issuance/offer" \
  -H 'Content-Type: application/json' --data-binary @-)

OFFER_URI=$(printf '%s' "$OFFER" | jq -er '.offerUri')

Open OFFER_URI with your wallet, or encode that exact URI as a QR code using a local QR renderer and scan it. Accept the credential in the wallet. Treat the offer URI as private; do not send it to an online QR service. The wallet completes the OpenID4VCI token and credential exchange with the issuer. Offer responses retain their existing camelCase fields, including id, offerUri, offerQrUri and expiresAt. Issuance status/list/update/cancel APIs remain keyed. For a keyless test, confirm that the credential appears in the wallet, then present it below.

2. Create a verification

VERIFICATION=$(jq -n --arg policy "$AUTHBOUND_POLICY_ID" '{policy_id: $policy}' |
  curl --fail-with-body --silent --show-error \
    "$AUTHBOUND_API_URL/v1/verifications" \
    -H 'Content-Type: application/json' --data-binary @-)

VERIFICATION_ID=$(printf '%s' "$VERIFICATION" | jq -er '.id')
CLIENT_TOKEN=$(printf '%s' "$VERIFICATION" | jq -er '.client_token')
ACTION_KIND=$(printf '%s' "$VERIFICATION" | jq -er '.client_action.kind')
ACTION_DATA=$(printf '%s' "$VERIFICATION" | jq -er '.client_action.data')

Verification responses use snake_case. Keep CLIENT_TOKEN private: anyone who has it can read this session until the token expires (default 15 minutes). Knowing the verification ID alone does not grant access. For ACTION_KIND=qr, render ACTION_DATA exactly as a local QR code and scan it; for link, open the exact value with the wallet. request_blob and dc_api require their corresponding wallet integration and must not be converted into invented deep links. Do not fetch a one-time request URI before the wallet does. Approve the presentation in the wallet.

3. Check status and retrieve the result

Poll the session with its bearer token; no publishable key is needed in enabled keyless testbed mode. Send the token in a header, never in a URL. Avoid shell tracing (set -x) and keep these variables out of logs.

STATUS=$(curl --fail-with-body --silent --show-error \
  "$AUTHBOUND_API_URL/v1/verifications/$VERIFICATION_ID/status" \
  -H "Authorization: Bearer $CLIENT_TOKEN")
printf '%s' "$STATUS" | jq -r '.status'

Repeat after a few seconds while the status is created, awaiting_user, awaiting_provider or processing. Stop for failed, canceled or expired. Only after status is verified, retrieve the signed result:

RESULT=$(curl --fail-with-body --silent --show-error \
  "$AUTHBOUND_API_URL/v1/verifications/$VERIFICATION_ID/result" \
  -H "Authorization: Bearer $CLIENT_TOKEN")

The response follows the existing signed result contract. The bearer token is bound to this session, testbed project and key set. A token from another session is rejected. The token-only result path requires verified; it does not return a successful result for failed or unfinished sessions.

Limits and errors

Response	Meaning and next step
`401` / `403`	Missing, invalid, expired or mismatched authorization. For creation, confirm keyless mode is enabled and omit all credential headers. For reads, use this session’s unexpired token. Token-only `/result` also returns `403` for unfinished or failed sessions; wait for `verified` before requesting it.
`400` `invalid_policy` on verification creation	Policy not found in the testbed project. Confirm the policy ID with the operator.
`404` on issuance offer	Credential definition not found or not published in the testbed project.
`400`	Check the operation’s request schema and claims. Malformed JSON below 256 KiB still consumes anonymous or keyed quota before parsing.
`413`	Enabled testbed creation requests exceed the 256 KiB raw-body limit. It applies before parsing and authentication, including keyed requests.
`429`	Honor `Retry-After`. Anonymous issuance and verification share 20 requests/minute and 300/hour across all testers. Unknown anonymous state fails closed during Redis outage.

Anonymous creation does not reuse Idempotency-Key: each retry can create a new offer or session. Keep the first successful response. Listing records, managing definitions/policies, canceling sessions and other administrative operations still require a key. The active wallet trust profile determines which credentials can be issued and verified; keyless access does not bypass wallet proof or trust checks.

Start here

Identity verification

Credential issuance

AI

Configure the test

1. Issue a credential

2. Create a verification

3. Check status and retrieve the result

Limits and errors

​Configure the test

​1. Issue a credential

​2. Create a verification

​3. Check status and retrieve the result

​Limits and errors

Configure the test

1. Issue a credential

2. Create a verification

3. Check status and retrieve the result

Limits and errors