Webhook endpoint being hit multiple times

Webhooks
1

Hi everyone,

A client and I are experiencing issues with our webhook endpoint being hit multiple times by Pipedrive. We’ve observed this issue with a number of different events as well (update.deal, added.activity, and added.note). Each one can produce 2-3 extra triggers on top of the first. This presents an issue as my client uses Claris Connect which counts its monthly step limit based on the number of steps each activated flow goes through. Right now, our flow has about 6 steps. These “ghost” triggers cause each event we want to trigger for our webhook to use about 24 steps towards our monthly limit.

I’d appreciate any help with stopping these extra triggers from happening. Below is the meta block of what was sent through the webhook the last time an event was run.

First one sent:

First
First1032×1156 106 KB

Second one sent:

Second
Second1034×1152 106 KB

Third one sent:

Third
Third1044×1158 106 KB

Fourth one sent:

Fourth
Fourth1046×1158 106 KB

1 Like
2

Hi, you didn’t include the part of the response JSON that shows the retry counter, but this sounds like something that could be caused by retried deliveries. According to Pipedrive docs, webhooks will be re-delivered if PD doesn’t get a response within 10 seconds or if the response code is not 2xx.

Just fixed a similar bug in my own code this week where I had erroneously assumed that a deal.added hook will never be called more than once per deal.

1 Like
3

Hi, thanks for your response.

I did forget to include the part of the JSON that shows the retry counter. After investigating, it was retrying because PipeDrive wasn’t receiving a 2xx response code. After correcting it, all seems well now. We went ahead and updated to v2 of the webhooks as well since we were already fixing things.

Thanks again for your help!

1 Like
4

Hi VNitsua, I’m having trouble getting Pipedrive to receive the 2xx response code, what is the syntax for that?

Currently I have something along the lines of:

try {
    var response = UrlFetchApp.fetch(apiUrl, options);
    Logger.log('Pipedrive response: ' + response.getContentText());

    if (response.getResponseCode() != 200) {
        throw new Error(`Pipedrive update failed with status code ${response.getResponseCode()}: ${response.getContentText()}`);
    }

    Logger.log('Successfully updated Pipedrive: ' + response.getContentText());
} catch (e) {
    Logger.log('Error updating Pipedrive: ' + e.message);
    throw new Error(`Address unavailable: ${apiUrl} - ${e.message}`);
}

}

// Helper function to create a response
function createResponse(message, statusCode) {
return ContentService.createTextOutput(JSON.stringify({ status: ‘success’, message: message, statusCode: statusCode }))
.setMimeType(ContentService.MimeType.JSON);
}

5

Hi, did you ever get the response code working correctly here? I’m having the same issue.

6

I realized my particular issue. I’m using Google Scripts for my automations. In the case of gScripts, don’t actually need to return anything. If you return with “ContentService.createTextOutput()” it counts as a 302 redirect and fails, but if you don’t return anything it works fine. But my issue was that my script wasn’t responding in <10s. So I ended up pushing all valid webhook requests to a gSheet immediately so the script could finish quickly. Then I tell the script to run those request rows from the gSheet every minute.

7

Bit of advice here. Try keeping with Google Cloud Run if you’re on GCP or AWS Lambda. At the start I shot myself a lot in the foot trying to host my own webhook consumer on a server and something is always going to fail. Cloud Run so far has been the best and handles large amounts of traffic without much trouble and managing it is pretty easy.

I use Fastly (Nodejs) on Cloud run and it’s really good. You’re basically just running a Docker container that has a server and you can control everything about the instance and the scaling is completely managed.