Pipedrive API Deprecations - 15 days before modules will stop working

[Marina]

Update: Pipedrive API v2 Transition Deadline Extended to July 31, 2026

Hello @here,

We are writing to share an important update regarding the transition of our Pipedrive integration from API v1 to v2, following our Pipedrive update email sent on Friday January 16, 2026.

First and foremost, we sincerely apologize for the pressure this transition has placed on you and your teams. We recognize that the previously communicated timeline required significant effort on short notice, and we truly appreciate your patience, understanding, and constructive feedback throughout this process.

With that in mind, we would like to inform you that in response to your feedback, we successfully coordinated with Pipedrive to push back the API v1 sunset, and have secured an extension of the grace period for the API v2 migration. Existing Make scenarios using affected API v1 endpoints will remain functional until July 31, 2026, to provide customers with sufficient migration time. After this date, access to Pipedrive API v1 endpoints will no longer be available.

This extension gives us valuable breathing room, and we intend to use it responsibly. Over the coming months, our engineering and product teams will be working diligently to:

• Continue refining and stabilizing the existing v2 modules
• Address and implement the feedback you have shared with us
• Identify and prioritize any missing or regressed functionality from the v1 experience
• Provide clearer guidance and support to help you update and remap affected scenarios with confidence

If you have already transitioned to the v2 modules, no action is required.

If you encounter any issues, missing features, or unexpected behavior while working with the v2 modules, please continue to let us know. Your feedback directly influences our priorities, and this extended timeline allows us to act on it more thoroughly.

Thank you again for your patience and for working with us through this complex transition. We remain fully committed to minimizing disruption and delivering a reliable, future-proof Pipedrive integration.

Make Team

[Lmar]

@Marina I’ve reached out to Make support to ask them to re-activate the V1 Pipedrive modules so that I could try using the “Swap App” feature with your DevTool extension. However support has said that V1 is no longer available. As @SierraV mentioned in this thread, I thought I would try the Swap App feature to help make this conversion process easier.

Since this does not appear to be possible, what are the other options to help ease this transition? You mention in this message that you plan to “Provide clearer guidance and support to help you update and remap affected scenarios”. Can you tell us what that will look like, and when you expect to provide this guidance? I want to know if I should wait, or simply muscle through this task manually, module by module.

A message to everyone using Pipedrive webhooks to trigger their scenarios:

• A while back Pipedrive introduced the ability to create custom webhooks via their automations. For example, if just one field is changed, you can create a trigger for that action and send a webhook to Make. Within this, you can specify exactly what fields you want to relay in that webhook. Pipedrive calls it “Automated Webhooks.
• Instead of a Pipedrive webhook created in Make that is listening for all changes in an Activity, you can listen for a very specific change. For us, this has reduced receiving webhooks by x10. This means a much lower use of Make credits.
• So in summary: Use the Pipedrive “Automated Webhooks”, and point them to a custom webhook receiver in Make.
• I’m using this transition as an opportunity to move most of my webhooks to this method.
  Here’s a resource: Automations: webhook requests - Knowledge Base | Pipedrive

[Anthony_PIQUET]

Hi Make team,

Context
We use Pipedrive through Make. Since the release of the new Pipedrive modules compatible with API V2 (replacing the API V1-compatible modules), we’ve noticed a functional regression in how custom fields of type “options” (single/multi-select) are handled.

Observed issue
With the API V2 modules, when we retrieve a Deal/Person/Organization, option-type custom fields return the value as an ID (and sometimes as a string enum), instead of the corresponding label.
Example: the field “Séniors - Source - Type” returns “124” instead of the related label.

Impact

• Breaks compatibility with our existing scenarios (which relied directly on labels).

• Requires adding an extra “resolution” step via an additional call (dealFields/personFields/organizationFields) and an ID → label mapping (or a Data Store cache).

• Increases complexity, processing time, and costs (operations/credits) to achieve what the API V1 modules provided directly.

Expected / Request

1. Please confirm whether this change is by design on the Make side (or on the Pipedrive side) for the new modules.

2. If expected, please consider improving the Make API V2 modules to optionally expose option labels, for example:

   • a “Return option labels” parameter (Make resolves via the Fields endpoints internally), or

   • an additional output (e.g., custom_fields_labels) with labels already mapped.

3. Otherwise, please share an official Make best practice for:

   • the ID → label resolution pattern,

   • optimization/caching strategy,

   • multi-select handling and text enums (open/won/lost/etc.).

Technical details (example)

• In V2 payloads, option fields return custom_fields.<field_code> = 124 (or open/won/lost/...) rather than a label.

• Resolving labels requires calling /api/v2/dealFields (or personFields / organizationFields) and mapping options[].id → options[].label.

Could you please let us know:

• whether there is already an option in the V2 modules to retrieve labels,

• otherwise whether an enhancement is planned, and what workaround you recommend officially?

Best regards,
Anthony

[Lmar]

I remember encountering something similar in the past after I added a new custom field in Pipedrive. When I did that, what I received in Make was the ID instead of the label.

Here was their resolution:

You will need to try editing your automation again - please, click on the action step with the custom field in question, edit it, and then click “save”. The button will appear after you try to apply any changes.

• When a custom field or a label is used in an action as a placeholder, all available options labels/names for these fields are fetched when the automation is Saved. If new options are added later for the custom field, the ID of the custom field would be used instead of the label/name.

By resaving the automation in Pipedrive, the custom fields started appearing correctly.

Your situation seems a bit different as it doesn’t appear you are using the Automated Webhooks in Pipedrive. I wonder if something similar needs to be triggered in Pipedrive in order for your custom fields to come across as labels instead of ID’s? Or, maybe it’s a Make thing where they are pulling ID’s instead of Labels?

[TT92]

@Marina @maketeam

Some feedback about the V1 API call. This shouldn’t be depreciated as there are still V1 endpoints in the API docs of Pipedrive.

I already migrated to V2 in december in all my Scenario’s, as i read the Developer docs of Pipedrive early 2025 Only now i see API v1 is also noted as deprecated..

[VeroniqueB]

We really need to have the choice between ID or label for custom fields in the new V2 Pipedrive modules as we had with V1 version. If not, the MAKE promess of quick and seamless development won’t be there anymore.

[Anthony_PIQUET]

Hi — thanks, that’s useful context.

I think there are two different issues that can look similar:

1. Make UI / metadata caching
   When you configure a Make module and select a custom field, Make fetches the field definition (including option labels) at “Save” time. If new options are added later in Pipedrive, Make can keep using stale metadata, and you may see IDs. In that case, opening the module, making any change, and hitting Save can refresh the option list. So your workaround makes sense for that scenario.

2. Pipedrive API V2 payload behavior
   Separately, Pipedrive API V2 often returns option-type field values as option IDs (or string enums), not labels. If Make’s new V2 modules are returning the raw API value, then re-saving won’t change the payload: you’ll still get IDs and would need an explicit ID→label resolution step via the Fields endpoints (dealFields/personFields/organizationFields) or a cached lookup.

So yes, we’ll try the “edit + save” refresh to rule out a metadata-cache issue. But given this is happening broadly after moving from V1 to V2 modules, I suspect it’s structural to the V2 modules returning raw IDs rather than labels.

If you’ve seen a case where the actual output value switched from ID to label (not just the dropdown/UI), I’d love to know which Make module/action you were using and whether it was tied to Pipedrive automated webhooks.

[TT92]

Unfortunately, Make cannot resolve this issue at the moment, as Pipedrive has updated its API endpoint and output data structure.

But you can easily map label or id using the map function.

First get all custom fields → Map options data → get your result!

Mapping is the new way to go via HTTP modules

[k.kitamura]

Hi everyone,

I’m auditing our scenarios for the upcoming Pipedrive API v1 deprecation and noticed a mismatch between the Make UI labels and the Scenario Blueprint identifiers. It makes me wonder whether we might be missing affected modules if we rely only on what’s marked “(Deprecated)” in the UI.

Example:

• In the Make UI, the module is labeled: “Search for Items” (not marked “(Deprecated)” on the Pipedrive integration page)

• In the exported Blueprint, the same module appears as:

  • “module”: “pipedrive:SearchOrganizations”

Since modules with the pipedrive: prefix (without -v2) typically indicate v1-based modules, this seems like it could be impacted—even though the UI label doesn’t warn about it.

Questions:

1. Source of truth: In cases like this, should we trust the Blueprint “module” identifier over the UI label / integration page label?

2. Hidden/unstated deprecations: Have you seen other modules that are not tagged “(Deprecated)” in the UI but export as pipedrive:* (non -v2) in the Blueprint?

3. Auditing at scale: For large accounts, are you scanning blueprints for pipedrive: (and then mapping which ones are v1 vs v2), or is there a better official method?

I’m concerned many teams may rely on UI labels and miss these, leading to broken workflows when v1 is fully turned down.

Any confirmation (or correction) on how Make maps UI modules to internal identifiers would be greatly appreciated.

Best regards,

Kenji

[Marina]

Hi everyone @here,

Thank you for the detailed reports and for clearly outlining the impact this change has on your scenarios. We’re genuinely sorry for the inconvenience this has caused you all.

After reviewing the behavior, we can confirm that this is driven by the design of the Pipedrive API V2. With API V2, Pipedrive returns option-type custom field values as IDs rather than resolved labels. That said, we fully understand the problems this creates on the Make side: broken compatibility with existing scenarios, the need for additional requests to field endpoints, increased scenario complexity, and higher operation usage.

We are aware of these challenges and agree that this represents a regression in usability compared to the previous modules. Internally, we need to discuss how we can best address this for our customers.

Please allow us some time to review this and come back to you with a solution. In the meantime, please feel free to open a ticket with our Customer Care team, who will be able to help you individually.

Thank you again for your patience and understanding.

Marina

[Anthony_PIQUET]

Hi Marina,

Thanks for the confirmation and for acknowledging the impact.

For us, having resolved labels (not only option IDs) is critical. A large part of our automations and downstream data flows were built on the V1 behavior, and the V2 output forces additional field-endpoint calls, extra mapping/caching logic, and significantly higher operation usage. This is not a minor change for us, it breaks production scenarios.

We’re counting on Make to provide a practical path forward, either:

• a workaround in the Make modules (e.g., an optional “return labels” mode that resolves IDs via the field endpoints internally), and/or

• escalating with Pipedrive to push for an API-level improvement (e.g., an option to return resolved labels in V2).

If it helps, we can share concrete examples of affected fields and scenarios, and we’re happy to test any beta fix quickly.

Thanks in advance for prioritizing this.
Best regards,
Anthony

[shapiroja]

Coming in late here and finding another seemlingly obvious field missing from new PD modules in Make.

For Create Activity, we have Deal, Lead and Project ID, but not Person ID? Not every activities is necessarily tied to an active deal or lead, but part of relationship management. I suspect this will be similar in other Activity modules (update, etc.)

How can I create an Activity and connect it to a Person if the PersonID is not an available field?!?

[Lmar]

I noticed this too.

In the past, they had “person_id” and “Participant” when creating an activity. This was consistent with V1 API docs.

Now when creating an activity you have “Attendee” or “Participant”, and “person_id” is missing even through this is still available in V2.

I think if you populate the person_id into the “Participant” field, it should work. I’m not sure why “person_id” was omitted in Make.

[Anthony_PIQUET]

Hello @Marina ,

Any news please ?

Thank you !

[leovahaianh]

Hello,

we are still discussing the feasibility of returning labels, please bear with us a little longer as this isnt an easy decision.

As for the missing fields in Create Activity module, the fix is ready and will be released next week.

Thank you,

Anh

[Palamatic]

Hello @Marina @leovahaianh

Any news please about options labels and IDs ?

Thank you !

[leovahaianh]

Hello Makers,

we are working on implementing the solution that would allow you to get labels in the output this week. Please give us a bit more time for testing this solution through.

Thank you,

Anh

[Surbhi_Sharma]

Hello @leovahaianh

Any news please about options labels and IDs ?

Thank you !

[Palamatic]

Hello,

Do you have any updates on this? It’s starting to become quite critical on our side. We have many scenarios that need to be updated, and we’re not sure whether we should start working on them now or wait for your solution.

[leovahaianh]

Hello Makers,

apologies it is taking longer than expected.

Apart from fixing many reported bugs above and via our Care team, we will release the possibility to get labels in the output for Get a Deal module (for the beginning) next week.

I will get back to you once these changes are out.

Anh