Two issues with webhooks

Hey! I have two questions regarding APIs and webhooks.

Currently, I’m working on an integration between my app and Pipeprive. I’m using App market to set up integration between both apps and I’m using tokens provided for developers and address to sent API requests.

Everything works fine and I’m able to create webhook that should send events whenever any kind of action occurs on person (so person.*). Now, something unclear is happening for me.

  1. When I create a new person in Pipedrive, I get two events - one is person.added and the other one is person.updated. What’s more weird, they do not always come in this order: added -> updated. Why there are two events sent in the first place? Behaviour like this really makes a mess.

  2. When I add any kind of action to a person, event for person.updated is also sent. Why is that? I see there are sections current / previous and there are differences for example in ‘next_activity_date’, but I wouldn’t expect that adding an activity triggers person.updated. I thought *.activity is reserved for sending such informations. At this moment I need to manually compare previous/current sections to chekc whether there are changes interesting for me and that’s not very handy.

Hi @majk,

Interesting questions there, let me take a look

Question 1)
Are you positive you don’t have any sort of automations that are being done once a person is created that would also trigger the person.updated webhook?

Question 2)
Yes, adding events will trigger the person.updated webhook if, as you stated, it also changes something such as ‘next_activity_date’

Hi @David,

Thanks for your response. About Q1 - I just did this quick test case:

  • I deleted all the webhooks I had, both in sandbox app (attached to my normal user) and dev ones I created using
  • To be completely sure about this, I did this new test using a completely new test URL to receive events
  • I even used your docs page to perform tests:
  • Via this page I checked if I had any webhooks on my user (negative), then I created a single webhook that triggers when person.* action occurs
  • In Pipedrive I created a new person with a name and phone number
  • I received both person.added and person.updated events

On more thing I just saw: both events contain same webhook id - “webhook_id”: “67878”

Q2) then I’ll have to continue to compare old/new parts of the event

I think I got the answer to this: “followers_count”: has chaged from 0 to 1. So probably that’s why there is a second trigger. Still, I think it’s a bug and there should be only one event when a person object is fully created.

Thanks @majk,

That does sound suspect regarding the follower count changing as I agree, that shouldn’t trigger an update event.
Let me do some investigating.

Hey @David,

Any updates on this one?

Hi @majk,

I spoke to one of our engineers and this is essentially his respond on this:

Creating a new deal might trigger the webhook as well (for example, if a new contact is created with this deal, it is not immediately visible in the payload, instead triggers some milliseconds later where the contact is added as a follower).

So if you are looking only at the last data sent by webhooks, you might see . BUT you should have associated before that, too.

Hey @David, thanks for your response.

Should doesn’t mean that’s gonna happen with 100% probability. If “deal” events are working the same way as “person” events, as I said, you can get sometimes both added and updated events in a reversed order. I suspect you have a race in your code or both events happen in different transactions, which means that even a little delay in processing ‘added’ event might cause ‘updated’ event to be received earlier.

For now, I have implemented a solution to that behavior on my side, that simply filters previous and current parts of incoming JSON events and checks for differences in fields that I’m interested in. If there are none, I pass on sending event further. That helps me to skip such case scenario we’re talking about and, unfortunately for you, is more fail-proof mechanism.

1 Like