Update a user.
Updates the specified user's properties. Only admins can perform this operation.
Authorization
Bearer JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.
In: header
Path Parameters
The unique identifier of the user.
The tenant identifier
The fields to update.
Defines the access level a user has within a tenant — a built-in role
ladder. Each role maps to a fixed capability (scope) bundle in
RoleScopeMap; that map, not these integer values, is the source of
truth for what a role can do and how roles order by privilege. The integer
values are stable storage identity only (do not renumber), so they are
deliberately NOT in privilege order — Fruxon.Model.Users.UserRoleType.Member (2, legacy) and
Fruxon.Model.Users.UserRoleType.Developer (4) sit at the same rung.
"UNSPECIFIED" | "ADMIN" | "MEMBER" | "OWNER" | "DEVELOPER" | "OPERATOR" | "VIEWER"Response Body
curl -X PATCH "https://api.fruxon.com/v1/tenants/string/users/string" \ -H "Content-Type: application/json" \ -d '{}'{
"id": "string",
"username": "string",
"email": "string",
"firstName": "string",
"lastName": "string",
"avatarFileId": "string",
"status": "INVITED",
"role": "ADMIN",
"effectiveScopes": [
"string"
],
"createdAt": 0,
"modifiedAt": 0
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}Update the current user's profile.
Partial update — only the fields present in the request body are applied; omitted fields remain unchanged. Use this for first-name / last-name / avatar changes triggered from the in-app profile settings. The caller can only mutate their own profile; identity is taken from the Firebase ID token, not from any path parameter.
Gets the current status of a long-running operation.
Returns the current lifecycle state of an async job (ingestion, refresh, deletion, etc). Clients should poll this endpoint until `status` reaches a terminal state (`DONE` or `FAILED`); intermediate states are `PENDING` and `RUNNING`. On success, `resourceName` points to the affected resource and `metadata` may carry provider-specific progress info — treat any progress signal as advisory and not strictly monotonic. On failure, `error` contains a human-readable reason. The operation id is the same value returned in the `name` field of the resource that started the job. Polling intervals of 1–5 seconds are reasonable; do not poll faster than once per second.