Webhook Classic vs New

Im converting my classic to the new platform. I have used custom actions on submit in my classic app and I using a webhook to make a call to my own server.

However I can only see Trigger ZAP and not Trigger Webhook. Is that I need to use the CALL API instead now ?

1 Like

This is only Business plan and above, right?

Call API is the one you’re thinking of, Trigger Webhook is available on all paid plans.

2 Likes

That is what I was remarking to. If he’s looking for the replacement, that is only on business.

@Dan_San was asking about Trigger Webhook.

The old Trigger Webhook has been deprecated and replaced with a new Trigger Webhook action, which is available on all paid plans.

Call API is a completely separate feature. And yes it only available on Business+
But that’s not what was being asked about, and it is not a replacement for Trigger Webhook.

2 Likes

Wow, I guess I missed the memo.

Its a different implementation.

In the original implementation I could setup a password and also pass a token through within the JSON object, but in the new implementation I am not seeing password AND it seems to be more sensitive on the JSON “values”

Also doesn’t look like you can name and reuse the webhooks in the new platform. I guess you need to create from scratch for each use, and if you need to make a change then change all manually. :frowning:

I need to rewrite my webhook

This is the old classic config

New implementation

The new Trigger Webhook action is actually “JSON-aware”.
What this means is that you cannot pass bare strings as values - they must be quoted.
If you want to pass JSON as a value, you should prepare it using a JSON Object or JSON Template column.

What I do is save each webhook URL as a Template column in my User Profiles table, and then refer to that whenever I need to use it. This also means that if it ever changes, I only need to update one column.

This alone makes the new Trigger Webhook feature far superior to the old one, where you couldn’t even edit or delete obsolete webhooks.

1 Like

lol… thanks… I’m still having my coffee and waking up. You saved my devs some pain…

Your suggestions is actually makes a lot of sense and agree… especially on the edit, that was a pain when you are trying to test and end up with lots of orphan webhooks.

Question :
In your implementation, when you have multiple webhooks (urls, passwords, json) do you create a webhook table and then create multiple columns to deal with the different webhook info. I am not seeing anyway of creating multiple rows, because the webhook implementation doesn’t have any filter allowing me to pull the required row ? or do I need to get some stronger coffee :slight_smile:

Darren suggested saving it as columns in your User Profiles table, then you can reference it anywhere, and that helps since the actions are table-specific.

I wouldn’t bother with a separate table, unless you have lots and lots of them.
This is what I have in my User Profiles table:

1 Like

Interesting.

Are you using “Single Value” columns inside the templates, so all users have access to the webhooks and if so where are you defining the source/raw webhook info in an options table ?

You can just point directly to those columns in the actions configuration. Pretty sure those templates contain the same URL.

What you see there is all there is. Each column is a template column that contains just the webhook URL. Any of the webhooks could be triggered by any User, so they need to be available in every row.

1 Like

Thanks Darren and Thinh

That’s simple, I was over complicating/engineering it in my head.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.