As the verification of webhooks has come up a couple of times and also I have had to pull information from other systems a couple of times recently to use in automations I thought some might like a brief run-through of cURL and using it for one-time API calls. This is one of those things that once you know it is simple but until you know it can seem very complex:
The video starts with a brief run-through of what cURL is and how it can be useful I then go through the process of activating a Tape application level Webhook using cURL to send in the codes to Tape.
Hopefully, it will be of help to some.
Also, some may notice that my API key is fully visible on some of the screens don’t worry it has now been changed
I know I was talking to you about this before. I feel I found a better way that doesn’t require the cURL verification. Making an http action with the destination webhook as the url and a request body with the data points mapped. Now I can pull data from multiple searches and connected records etc into one webhook data package. I’m curious though, why tape doesn’t explain to do it that way instead of this overly complicated method. Am I not supposed to be doing it how I’m doing it? Ha
Hi @DB_Looper. It was not my intention to suggest that using cURL is the only method to verify webhooks. As far as I know, the Tape Team isn’t advocating for a specific approach either. You have the flexibility to verify webhooks using the method that suits your needs and circumstances best. In this thread: [✅ Solution] Developer Webhook -> Zapier (401 error) it was done directly from Zapier. I personally find using cURL very useful for quick API calls including verifying webhooks, but I understand that different users may have different preferences.
However, I think what you are actually saying is that you switched from using an application-level (Developer) webhook to using an automation-level webhook. I don’t believe there is any specific push to use application-level (Developer) webhooks. Application-level webhooks have a very good place when performing actions such as duplicating entire records into SQL databases etc, as they can act as a trigger for follow-up API calls but for transferring specific fields into other systems, then I couldn’t agree more: sending data via HTTP in automations is often a more straightforward approach.
I am pleased you found an easier way to achieve what you were trying to do.
No for sure its good to have multiple choices.
I’m still getting into doing things outside of just mapping fields when it comes to automation, so figuring out the http call made me happy. Hah. I guess its an obvious solution, but I was surprised there was no forum or help article on it. Maybe I’ll make one.
