In v1, modules like Get a Deal returned embedded data for related records — for example, the deal owner's name and email appeared directly in the response. In v2, those fields return only a numeric ID (owner_id, person_id, org_id, creator_user_id).

If your scenario mapped the owner's name or a person's email directly from a deal response, that data is no longer included by default. To retrieve it, either:

In v1, single- and multiple-option custom fields returned both the option ID and its readable label. In v2, they return only the ID.

The Get a Deal module includes a Show labels option to retrieve the human-readable label alongside the ID. Like Extend output, enabling Show labels triggers an extra request and a small additional credit cost.

In v1, custom fields and their sub-fields were spread across the top level of the record, sometimes with separate keys. For example, a currency field had a standalone _currency key. In v2, all custom fields sit under a single custom_fields object, with related properties nested together:

Update any mappings that referenced the old flat keys directly.

V2 dropped fields that v1 computed automatically. The following are no longer returned:

Fetch the related record to retrieve its name. Compute formatted or weighted values in your scenario if needed.

Activity counts, follower counts, and similar metrics are no longer returned by default. You must opt in using the include_fields parameter. Pass this parameter as a comma-separated string — passing it as an array means the extra fields don't return.

Address and location data moved from multiple flat fields (for example, address_route, address_locality) into a single nested object with sub-properties. Update any mappings that pointed at the old flat address keys.

Several fields were renamed in v2. Update your mappings where you reference the following:

Labels: The label field changed from a comma-separated string (for example, "3,7") to an array of integers ([3, 7]). When mapping labels, provide integer IDs in array form. Supplying a comma-separated string or non-integer values returns a This value should be of type integer or Label not found error.

Custom field names in module output: Where field labels were used as parameter names, use the underlying field code instead. Renaming a custom field in Pipedrive won't break your mapping when the field code is used.

V2 validates request data more strictly than v1.

Numbers must be real numbers. Option IDs and numeric custom fields must be sent as numbers, not strings. If a mapped value arrives as a string, v2 rejects it with an error such as "Expected 'number' as option ID for multi options custom field." Use parseNumber() where a mapped value comes through as text.

Booleans are true/false, not 1/0.

Empty values are rejected. You can't leave a custom field blank. V2 refuses an empty string with an error like "Expected non-empty 'string' as short text custom field value." For number fields, null, ifempty(...; ignore), and erase are all rejected — and sending 0 is accepted but treated as the value zero, not as empty. To avoid errors, don't send empty string values for custom fields. Apply a formula to conditionally include the field only when it has a value. For example:

All timestamps in v2 use RFC 3339 format with an explicit timezone (for example, 2024-01-01T00:00:00Z). For activities, the single due date and time concept split into two separate string fields: due_date and due_time. Treat these as distinct values in your mappings.

V1 used offset-based pagination (start and limit). V2 uses cursor-based pagination (cursor and limit). This is handled inside the modules. If you built custom pagination logic around page offsets using Make an API Call, update that logic to use cursor-based pagination.

V1 update endpoints used HTTP PUT. V2 uses PATCH. If you send update requests through Make an API Call, verify the method is set to PATCH.

The item search endpoint renamed several parameters in v2:

Update these parameter names in any custom API calls that drive search.

Not every Pipedrive resource has a v2 equivalent. The following remain on v1:

If a v2 module fails where the v1 module worked on the same connection, the cause is likely one of the following:

If you encounter unexplained 404 errors on a v2 module, reconnect the Pipedrive account and try again.