Two storage levels: UIID lets you store structured data directly on a user's identity instead of building your own database. Data can live on the Core ID (via /api/v1/core/data) or inside a specific Alias (via the /api/v1/aliases/data endpoints), depending on how central or context-specific the information is.
Writing to the Core ID: POST /api/v1/core/data stores encrypted, application-specific settings directly on the user's Core ID. The request body takes a key, a value, an optional is_public flag, and an optional is_immutable flag (this requires the storage:immutable scope).
Reading Alias data hierarchically: GET /api/v1/aliases/data/{id} fetches every data node stored under an alias and automatically reconstructs it into one nested JSON object — for example a profile object and a settings object returned together, rather than as separate flat keys.
Writing Alias data: Two write modes are available. POST /api/v1/aliases/data is a full overwrite that replaces the entire data store for an alias, so use it with caution. PATCH /api/v1/aliases/data is a partial update using dot notation (for example "profile.theme": "dark"), which only touches the keys you specify.
Immutable nodes: Setting is_immutable: true on a key locks that specific key-value pair permanently — it cannot be modified once set, and it also blocks full account deletion until it is removed by the application provider. If a user wants an immutable node gone, they call POST /api/v1/aliases/storage/request-deletion, which notifies the provider rather than deleting it directly.
Removing data: Regular (non-immutable) keys can be removed directly with DELETE /api/v1/aliases/data, and an entire alias — including all of its data nodes — can be purged from the network with DELETE /api/v1/aliases/{id}.
Shared buckets (new in v2.6): POST /api/v1/aliases/members adds another UIID to a specific data bucket, enabling real-time data exchange between two identities inside the same alias context — for example a defined chat_partner role. GET /api/v1/aliases/members/{alias_id} lists everyone with access, along with their role and when they were added.
Why this matters for developers: Because the data lives on the user's own identity rather than in your database, you don't need to run your own storage layer for user-specific app data — and the user keeps a portable, structured record that travels with their UIID across apps.