Retrieve a User

Use these endpoints to look up a single user record in DealHub CPQ. Two lookup methods are available, by login identifier and by DealHub user ID, and both return the same response structure. Choose the method that matches the identifier your system has available at the time of the request.

Prerequisites

Before making any requests on this page, ensure the following are in place. Both endpoints require a valid authentication token and the identifier of the user you want to retrieve.

  • DealHub Authentication Token: Include the token in the Authorization header of every request. For instructions on generating a token, see Authentication.
  • A user identifier: You must have either the user's login string or their DealHub-assigned id. If you have neither, use Get a List of Users to retrieve user records and locate the identifier you need.

The Retrieval Workflow

Each time your integration needs to look up a user, complete the following steps:

  1. Choose your lookup method based on which identifier your system holds: login or DealHub user id.
  2. Send the request from your backend using the appropriate endpoint.
  3. Handle the response and extract the user fields your integration needs.

Step 1: Choose Your Lookup Method

Both endpoints return identical responses. The difference is only in how you identify the user.

📘

Default to Get User by Login

In most integration workflows, the consuming system already holds the user's login, it is the value your system assigned when the user was first provisioned. Use the Get User by ID endpoint only when you have the DealHub-assigned id on hand, such as when processing a webhook payload that returns it directly.

Step 2: Send the Request

Get User by Login

Retrieves a user record based on their login identifier.

Method: GET

URL: /api/v1/user/login/{login}

Path parameter:

ParameterDescriptionNotes
loginThe login identifier of the user to retrieve.Max length: 100 chars

Get User by ID

Retrieves a user record based on their DealHub-assigned user ID.

Method: GET

URL: /api/v1/user/id/{id}

Path parameter:

ParameterDescriptionNotes
idThe DealHub user ID of the user to retrieve.Max length: 16 chars

Step 3: Handle the Response

A successful request returns HTTP 200 and a JSON object containing the user's profile.

{
  "login": "john@my_domain.com",
  "id": "786865656908",
  "email": "john@my_domain.com",
  "name": "John Smith",
  "position": "Sales",
  "phone": "09-445556",
  "mobile": "023-6654464",
  "fax": "09-756576",
  "company": "My Domain",
  "street": "Harokmin 26",
  "city": "Holon",
  "state": "Center",
  "country": "Israel",
  "postal_code": "563733",
  "is_active": true
}
📘

Null fields are omitted

Fields with a null value are not included in the response. If a field does not appear, its value is not set for that user.

Response fields:

FieldDescriptionAlways present
loginLogin identifier of the user.Yes
idDealHub-assigned user ID.Yes
emailPrimary email address of the user.Yes
nameFull name of the user.Yes
is_activeWhether the user is active in CPQ. Inactive users cannot access DealHub.Yes
positionThe user's role in the organization (job title). Displayed in the CPQ UI as Position. Referenced as USER_TITLE in document template parameters.No
business_titleBusiness title of the user in the CRM organization. Not displayed in the CPQ UI. Referenced as USER_BUSINESS_TITLE in document template parameters.No
phoneUser phone number.No
mobileUser mobile phone number.No
faxUser fax number.No
companyUser company name.No
streetStreet name.No
cityCity name.No
stateState name.No
countryCountry name.No
postal_codePostal code.No
user_manager_loginLogin identifier of the user's manager.No
🚧

Check is_active before routing a user into CPQ

If your integration routes users into DealHub as part of a downstream workflow, verify that is_active is true before proceeding. Inactive users cannot access CPQ and the session will fail.

📘

Retrieve a user before updating them

Before sending an update request, retrieve the current user record to confirm the user exists and inspect which optional fields are already populated. This prevents accidentally overwriting existing field values with empty ones.

Next Steps

Now that you understand the core concepts, proceed to the practical guides:

📘

Related API Reference

The following API Reference pages document the endpoints used in this guide: