list_user_attributes last
in the display order.
This writes to every existing user. The attribute is opened on each one
of them at creation, empty, except a bool, which starts at false for
everyone. An amount attribute also records the company currency there. So
creating an attribute touches the whole user table, not just the definition.
Set values per user with
update_user_attribute_values,
and the value new users start with with
update_user_attribute.
The call is refused when the key is in use or reserved, when unique is set
on a type other than string or float, or when options is missing for a
picklist or given for another type.
Creating the people is not done here: that happens in the Qobra web app,
which is also where an attribute synced from an HRIS or a CRM is set up.
Every write is recorded in the audit trail as the Qobra MCP agent.
Parameters
Body
Body
string
required
Display name, e.g. ‘Segment’.
string
required
Stable key, unique among the company’s attributes: lowercase letters, digits
and
_ only, stored as sent (‘hiring_date’). The public API serves each
user’s attribute under it, so ‘id’, ‘email’, ‘status’, ‘name’, ‘role’,
‘currency’ and ‘calculation_currency’ are taken.string
required
‘amount’ is monetary, ‘percentage’ a ratio (0.15 reads as 15%), ‘float’ a
plain number, ‘user’ a Qobra user, ‘picklist’ one label out of
options and
‘multipicklist’ several. One of: float, amount, percentage, string,
picklist, multipicklist, bool, date, user.string[]
The labels to choose from: required for a picklist or multipicklist, refused
on any other type.
boolean
Add it as a column of the statement exports (the users export always carries
every attribute).
boolean
Refuse two users the same value (employee number, payroll id). Only for a
‘string’ or ‘float’ attribute.
Response
Body
Body
object
The attribute as it now exists — the same row list_user_attributes
returns, so the id can be reused straight away.