Data Exchange — users¶
All paths are relative to /data_exchange/api/v1/users.
| Method | Path | Purpose |
|---|---|---|
GET |
/get_user |
get the authenticated user |
GET |
/get_user/{user_id} |
get a user by ID |
POST |
/import_user_in_consumer_format |
standardize/process one raw user |
PUT |
/{user_id} |
update by user ID |
Consumer-format imports always use the pwc data source.
The import runs with call_from_consumer=True. Before standardization, it
archives the input under
pwc/{environment}/{client_name}/message/raw/user/{partyId}_{date}.json when
BLOB_ENDPOINT is configured. Unchanged
profiles keep their existing timestamp so matching only reruns when scores are
missing or stale.
The import contract continues to accept legacy education and certification
fields for backward compatibility. User standardization ignores these values;
they do not participate in enrichment, search or newly standardized user data.
Bookmark entries without a usable entityId are also discarded before
persistence. Missing, null, NaN, empty and whitespace-only identifiers are
invalid. Duplicate identifiers keep their first occurrence and source order;
valid string identifiers such as "007" are preserved verbatim.
When DATABASE_URL is configured, GET requests read the live relational user
projection and ignore MongoDB tenant-database routing. The PUT route updates
only the AIHub-owned isAdmin and
chatbotSimulationAcknowledgementDate fields in PostgreSQL.
userApplicationId is always copied from the relational user's primary key and
cannot be updated through this API. The PostgreSQL projection intentionally does
not expose biography or project fields.
Opportunity and training visibility use distinct user fields. accessGroup
contains the PwC-only opportunity groups, while trainingAccessGroup contains
the Smart Editor training groups (flag_id = 3). Both fields are optional in
the public response contract and are represented as lists when standardized.
trainingHistory is read from the same-tenant Smart Editor attendance
associations (flag_id = 4) in PostgreSQL mode and from the equivalent
synchronized data in MongoDB mode. Each entry contains trainingId, title
and a nullable completionDate; the date is null when the source contains no
business completion date.
The generated data exchange HTTP reference is the authoritative source for parameters, schemas, responses and examples.