Send the new user's details in the request body as a User object. For the full list of attributes, see the User model.

To create a user, you need to include these fields:

• userName — must be a valid email address
• name.givenName
• name.familyName
• active

Some attributes point to objects that must already exist in Perk. If you pass a value Perk can't find, the request fails and Perk doesn't create or update the user. These attributes are:

• invoiceProfiles — every payment profile in the list must already exist in Perk.
• travelPolicy — the travel policy must already exist in Perk.
• manager — the manager's Perk user ID, passed as a string (for example, "12345"). The user must already exist and be active in Perk.
• lineManagerEmail — the login email of an existing, active Perk user. Use this instead of manager when you provision users through an identity provider (such as Okta) that can't reference users by ID. You can send both, but lineManagerEmail takes precedence.
• approvers — an array of valid Perk user IDs. Each approver must already exist and be active in Perk, and when you assign approvers, Perk creates an approval process for the user. This field is still supported but deprecated for most customers — use manager or lineManagerEmail instead.

The costCenter attribute behaves differently. By default, Perk matches the value to an existing cost object by name (case-insensitive). If no match is found, Perk creates the cost object and assigns the user to it. Perk can disable automatic cost object creation for a SCIM integration. When disabled, an unmatched costCenter value is skipped and the user's cost object is left unchanged, contact your Perk representative if you need this configuration.