Overview
What Account covers, envelopes, email immutability, and what is deferred.
What this reference explains
Account is the end-user profile surface: load the authenticated user, update display fields (including an optional profile picture upload), change password, and read which product features are enabled for that user.
In the product UI the route is /profile (also reused under admin/super-admin profile wrappers). The panel prefers POST /user with multipart/form-data for profile updates so a file can be attached; PUT /user accepts the same fields as JSON when no file is uploaded.
Response envelope
Profile and password endpoints use the panel shape {"success": true|false, "data"?: ..., "message"?: "..."}. GET /me/features returns only {"data":{"features":{...}}} — no success key.
GET /user merges four workspace context keys onto the user array. PUT/POST /user return the Eloquent user JSON without those four keys.
Email is not writable here
Profile update validates only name, phone, company, bio, and optional profile_picture. Email is returned on read but is display-only in the Profile UI and is not accepted by the update method.
Feature availability
These Account routes are not gated by a feature flag. Any authenticated caller under the route middleware can use them. There is no feature:account 403 body. The feature map itself (GET /me/features) is how the UI learns which other modules are enabled.
Out of scope here
- Reseller UI version / intro seen (
PUT /user/reseller-ui-version,POST /user/reseller-ui-intro/seen). - Developer zone OAuth clients and personal access tokens (
/developer/*, featureintegrations). - Admin / super-admin user CRUD and feature admin writes.
- Public auth (login, register, forgot/reset password, email verification send/resend).
- Team workspace management (Team module) and Connect GoHighLevel.