Description
Please, read first https://dru-id.com/developers/apis/oauth-2/ to learn about Oauth2 protocol and the meaning of each token.
The PATCH method allows clients to perform partial updates on an existing resource. Unlike a full UPDATE (typically implemented as a PUT request), which requires the complete representation of the resource, a PATCH request only needs the specific fields that must be modified. This makes PATCH more efficient and precise, especially when working with large or complex data structures.
With this method, it is possible to set one or more parameters to null in order to remove them from the resource. However, certain constraints apply when working with confirmable identifiers such as email addresses, phone numbers, or any other ID that requires user verification.
If you send several fields to update in the same object and one of them fails (due to validation, conflict, or any internal server error), then none of the changes provided for that resource will be performed.
You must set the HTTPContent-Typeheader to application/jsonl to indicate that the request payload is formatted using JSON Lines (JSONL).
JSONL is a structured format where each line contains a single, valid JSON object, making it efficient for streaming, incremental processing, and handling large datasets.
Unlike traditional JSON arrays, JSONL allows the server to process records line by line without requiring the entire payload to be loaded or parsed at once.
You must encode the request body using the universally supported UTF-8 character set.
User Identification Requirements
To perform a PATCH operation, the target user must be clearly identified.
You must include either the object_id or the pulse_id in the user onject.
At least one of these identifiers is mandatory for the request to be valid.
Supported Input Elements
This method accepts any combination of the following elements:
A. Identifiers (IDs)
You may delete or replace identifiers under the following rules:
Deleting IDs
An identifier can be deleted only if it is not confirmed. Confirmed identifiers cannot be directly removed.
Replacing IDs
Identifiers may be replaced. The behavior differs depending on whether the existing identifier is confirmed:
Replacing a confirmed identifier*
The system sends a notification (email, SMS, etc.) to the user requesting confirmation of the new identifier.
Until the user confirms the new value, the database retains the previous confirmed identifier.
Replacing a non-confirmed identifier
The system updates the identifier immediately.
Adding New Identifiers
When adding a new identifier, the system applies the same rules used for replacement:
If the new identifier is confirmable
The user must confirm it. The system sends a notification, and the new identifier is not activated until the user completes the confirmation.
If the new identifier is non-confirmable
The system immediately stores the identifier without requiring further validation.
*A “confirmed identifier” is one that has already been validated by the user or is required to be confirmed by the entrypoint’s policy.
B. Data Fields
Data fields are simple: assign null to remove a value, or provide a new value to update it.
C. Addresses
Address objects may be deleted by assigning the entire address to null.
Individual fields within an address may also be removed by setting those fields to null.
Important: An address object must always include both direction and postalCode fields.
If either is missing, the address is considered invalid.
D. Assertions
Assertion objects cannot be deleted.
To reject an assertion, update its value to false.
Redirection After Confirmation
When a confirmable identifier is updated, the user may be redirected to a URL specified in the request context after completing the confirmation process.
This redirect will only occur if the provided URL is included in the cockpit’s app whitelist, ensuring secure and controlled navigation.
Data validation
The system will validate the data constraint associated with an entrypoint. However, you can provide a different entry point for each user. If an entrypoint is not explicitly provided for a user, the system will automatically select the entrypoint associated with the user at registration time.
Endpoint URL:
PATCH https://{your-endpoint-domain.com}/activityid/v1/user/bulk
Headers
| Parameter | Description | Type | Required |
|---|---|---|---|
| Authorization | “Bearer app_token” Literal text Bearer followed by app_token that is the token obtained from /oauth2/token endpoint | string | yes |
| Content-Type | The type of content that will be used for requests to be JSON. Must be application/jsonl | string | yes |
| Accept | The type of content that will be used for responses to be JSON | string | yes |
| Accept-Language | Language for this request. This language will be used to send the confirmation notifications if needed | Locale | no |
Query string parameters
None
Request Example
| Parameter | Description | Type | Required | Value |
|---|---|---|---|---|
| object_id | Current object_id of the user. | string | yes | … |
| pulse_id | Current pulse_id of the user. | string | yes | … |
| entrypoint | Entrypoint for applying the data validations. If not provided the system will get the entrypoint from where the user was registered. | string | no | ‘my-entrypoint’ |
| redirect_url | Where to redirect after confirming the ids if any. | string | no | ‘https:mysite.com’ |
| changes | The array of users to be updated | struct | yes | … |
| changes.ids | Ids to be changed. | struct | no | … |
| changes.datas | Datas to be changed | struct | no | … |
| cahnges.addresses | Addresses to be changed | struct | no | … |
| changes.assertions | Assertion to be changed | struct | no | … |
Response examples
Response: Bulk User Patch OK
| Parameter | Description | Type |
|---|---|---|
| content.bulkId | The id of the bulk process. You will needed to query the status and the results of the operation | string |
| result | Common http result | struct |
| result.status | Http code | integer |
Response codes
| Code | Type | Description |
|---|---|---|
| 400 | Error | Bad Request: The request could not be understood by the server due to malformed syntax |
| 401 | Error | Unauthorized: authentication is required and has failed or has not yet been provided (token is invalid, etc) |
| 413 | Error | The request body exceeds the permitted limit. |
| 500 | Error | Internal Server Error: The server encountered an unexpected condition which prevented it from fulfilling the request |
| 504 | Error | Gateway TimeoutService can not contact with oauth server to do some internal operations |
| 202 | Accepted | The Bulk process has started successfully. |