Get user details

This walkthrough reads and maintains a member you’ve already created (Create a user).

export API_BASE_URL="https://api.develop.fourdos.dev"
export API_KEY="org_…"
export USER_ID="0198f2b1-…"

1. Fetch the profile

curl "$API_BASE_URL/v1/users/$USER_ID" \
  -H "Authorization: Bearer $API_KEY"

200 OK:

{
  "id": "0198f2b1-…",
  "email": "ada.lovelace@example.com",
  "display_name": "Ada L.",
  "first_name": "Ada",
  "last_name": "Lovelace",
  "country": "GB",
  "age_band": "adult",
  "dob_verification_status": "self_declared",
  "last_active_at": "2026-07-17T09:12:00.000Z",
  "status": "active",
  "wallet": { "status": "active", "address": "0x…" },
  "membership": {
    "id": "…",
    "external_id": "cust-001",
    "role": "member",
    "status": "active",
    "joined_at": "2026-07-17T00:00:00.000Z",
    "locked_at": null,
    "locked_reason": null
  }
}

The read is scoped to your organization: a user who exists on 4D but isn’t a member of your org is a 404, not a 403 - membership is what makes them visible to you. The profile is the redacted partner view: you get the derived age_band, never the raw dob.

2. Update profile fields

PATCH takes any subset of the profile fields:

curl -X PATCH "$API_BASE_URL/v1/users/$USER_ID" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "display_name": "Countess of Lovelace", "locale": "en-GB" }'

200 OK returns the updated user. Validation matches creation: country must be an assigned ISO alpha-2 code, dob a real past date.

3. Set typed attributes

Beyond the fixed profile, your org’s enabled attribute registry holds custom typed fields (Members). Write values by key:

curl -X PUT "$API_BASE_URL/v1/users/$USER_ID/attributes" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "values": [
      { "key": "phone", "value": "+44 20 7946 0000" },
      { "key": "shirt_size", "value": "m" }
    ]
  }'

200 OK:

{
  "values": [
    { "key": "phone", "value": "+44 20 7946 0000", "provenance": "partner_api" },
    { "key": "shirt_size", "value": "m", "provenance": "partner_api" }
  ]
}

Values are validated against each key’s definition - a single_choice attribute rejects values outside its configured choice list, an attribute key your org hasn’t enabled is rejected outright. Every stored value carries provenance, so an API-written value is always distinguishable from one an admin, the member, or a bulk import wrote. To clear a value, send the key with "clear": true and no value. Set and clear entries can share one request; each key may appear only once:

curl -X PUT "$API_BASE_URL/v1/users/$USER_ID/attributes" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "values": [
      { "key": "shirt_size", "value": "l" },
      { "key": "phone", "clear": true }
    ]
  }'

200 OK. The cleared value is deleted, so the response lists only the values that were set:

{
  "values": [
    { "key": "shirt_size", "value": "l", "provenance": "partner_api" }
  ]
}

A clear is never inferred from an empty string: "" is a value, and a choice attribute rejects it. An entry with both clear: true and a value, an entry with neither, or a key repeated in one request is rejected with 422 ATTRIBUTE_INVALID_VALUE.

4. Read stored attributes

curl "$API_BASE_URL/v1/users/$USER_ID/attributes" \
  -H "Authorization: Bearer $API_KEY"

200 OK:

{
  "values": [
    { "key": "phone", "value": "+44 20 7946 0000", "provenance": "partner_api", "updated_at": "2026-09-15T12:34:56.789Z" },
    { "key": "shirt_size", "value": "m", "provenance": "partner_api", "updated_at": "2026-09-15T12:34:56.789Z" }
  ]
}

Org keys and partner admin sessions read members in their organization. A platform admin session reads the tenant selected as its active organization. Member sessions cannot use this partner read. The list contains stored values for enabled, active attribute definitions. Each value keeps its JSON type and provenance; updated_at is the stored value’s last update as an ISO timestamp. Unset and cleared values are absent. A member with no stored values returns { "values": [] }. Unknown, removed and other-organization members return 404. Core profile fields, including raw date of birth, are absent because they have no attribute-value row. Read those through the profile endpoint, which redacts raw DOB for partner readers. This attribute read creates no audit, attribute or idempotency records and ignores Idempotency-Key.

Common errors

Status	Code	Meaning
`404`	`NOT_FOUND`	The user isn’t a member of your organization
`422`	`VALIDATION_ERROR`	A field failed validation - `details` carries per-field errors
`422`	`ATTRIBUTE_UNKNOWN` / `ATTRIBUTE_DISABLED`	The attribute key does not exist, is retired, or your org has not enabled it
`422`	`ATTRIBUTE_INVALID_VALUE`	The value does not fit the attribute’s definition, or the entry is malformed
`401`	`UNAUTHORIZED`	Missing or invalid API key

Get started

Concepts

Walkthroughs

Content API

SDK

1. Fetch the profile

2. Update profile fields

3. Set typed attributes

4. Read stored attributes

Common errors

​1. Fetch the profile

​2. Update profile fields

​3. Set typed attributes

​4. Read stored attributes

​Common errors

1. Fetch the profile

2. Update profile fields

3. Set typed attributes

4. Read stored attributes

Common errors