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
Authorizationheader of every request. For instructions on generating a token, see Authentication. - A user identifier: You must have either the user's
loginstring or their DealHub-assignedid. 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:
- Choose your lookup method based on which identifier your system holds:
loginor DealHub userid. - Send the request from your backend using the appropriate endpoint.
- 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 LoginIn 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-assignedidon 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:
| Parameter | Description | Notes |
|---|---|---|
login | The 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:
| Parameter | Description | Notes |
|---|---|---|
id | The 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 omittedFields 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:
| Field | Description | Always present |
|---|---|---|
login | Login identifier of the user. | Yes |
id | DealHub-assigned user ID. | Yes |
email | Primary email address of the user. | Yes |
name | Full name of the user. | Yes |
is_active | Whether the user is active in CPQ. Inactive users cannot access DealHub. | Yes |
position | The 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_title | Business title of the user in the CRM organization. Not displayed in the CPQ UI. Referenced as USER_BUSINESS_TITLE in document template parameters. | No |
phone | User phone number. | No |
mobile | User mobile phone number. | No |
fax | User fax number. | No |
company | User company name. | No |
street | Street name. | No |
city | City name. | No |
state | State name. | No |
country | Country name. | No |
postal_code | Postal code. | No |
user_manager_login | Login identifier of the user's manager. | No |
Checkis_activebefore routing a user into CPQIf your integration routes users into DealHub as part of a downstream workflow, verify that
is_activeistruebefore proceeding. Inactive users cannot access CPQ and the session will fail.
Retrieve a user before updating themBefore 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:
- Get a List of Users: Retrieve all users or filter by active or inactive status.
- Update Users (v1): Update one or more existing user records.
- Create or Update Users (v2): Create new users or update existing ones in a single call.
Related API ReferenceThe following API Reference pages document the endpoints used in this guide:
Updated 18 days ago
