Decide the level first. Data belongs on the Core ID (/api/v1/core/data) if it is central to the person across contexts, and inside a specific alias (/api/v1/aliases/data) if it only makes sense within one context. Most application state belongs on the alias.
Design for hierarchical reads. GET /api/v1/aliases/data/{id} reconstructs every node under an alias into one nested JSON object — a profile object and a settings object returned together. Name your keys so that structure comes out clean.
Use PATCH, not POST, for updates. POST /api/v1/aliases/data is a full overwrite that replaces the entire data store for that alias. PATCH takes dot notation such as "profile.theme": "dark" and touches only what you name. Reach for POST deliberately or not at all.
Be careful with is_immutable. It locks a key-value pair permanently and blocks full account deletion until the application provider removes it. Users then have to call POST /api/v1/aliases/storage/request-deletion and wait for you. Use it only where permanence is genuinely the requirement.
Plan for deletion from day one. A user can purge an entire alias with DELETE /api/v1/aliases/{id}, including every data node under it. Your app should degrade gracefully when its stored state simply is not there any more.
Why this is worth doing well: the data lives on the user's identity rather than in your database, so you do not run a storage layer — and the user keeps a portable record that travels with them.