Hey @Remco_CS & @paulieweb
Thanks for bringing this to our attention. If I understand you correctly, you seem to use the Web App / Script URL as a trigger to receive payloads from Pipedrive webhooks.
The general recommendation is to use a secure trigger URL (with basic authentication at least) to handle the incoming webhook payload. This URL should also return an appropriate status code if something goes wrong / if the trigger is not accessible.
Like @Remco_CS pointed out, one can use either Google Cloud Functions or AWS Lambda (with a secure HTTP trigger) as a proxy that communicates with the web app URL. This is relatively safe, reliable, and could be an extremely cost-effective approach if the invocations are not that high.
On current setups that rely solely on Google Apps Script (GAS)
There are a few factors that could affect the redirection behaviour. Do you happen to use ContentService to return data in
If you use ContentService,
- the app receives your payload,
doPost(e) and then
- redirects to some other page to show the content with appropriate status code
Note: This behavior can only be spotted if you make the Postman / REST client not follow the redirects. This would be the case when PD webhooks no longer follow redirections. They will simply see a 302 status code from GAS
If you do not use ContentService to return anything,
- the app receives your payload
doPost(e) and simply returns 200 status code (doesn’t redirect)
Removing the ContentService could eliminate the status code challenge but it opens new challenges. For instance, PD will notice that all webhook triggers return a successful 200 and won’t retry even if there’s an actual failure. Such failures will only be visible on GAS. Also, there’s this constant security threat of having an exposed Web App URL that could be misused (which I would definitely try to avoid )
Let me know if it helps