Inbound Webhook Response (Respond to an *inbound* webhook trigger)
D
Donald Moore
Now that we can save the response from an outbound webhook inside of a workflow, if we could now get a response from an Inbound Webhook Trigger, we could eliminate the need to match custom values and custom fields to their respective hashed IDs in the system.
This way, you could basically use HighLevel like a stateful "headless" CRM without the pain of having to create tables of Custom Values and retrieve the hash each time you create a Custom Value or a Custom Field.
Log In
A
Ashwin Raghunandan
Merged in a post:
Custom Responses for Inbound Webhook
R
Robin de Niet
It would be very helpful to edit the response for a succesful (at least) inbound webhook. In my case, I need to give a specific response { “success”: true } for the other server to not retry 6 times to send me the data.
G
Georg Kormacev
I'm new to GHL and I struggle with webhooks. So you are saying we can store a webhook response? How? I mean the normal webhook, not the custom webhook. I think this should be possible with normal webhooks too. I tried
- {{webhook}}
- {{webhook.result}}
- {{webhook.response}}
But nothing worked. Any idea?
B
Brock Jeppesen
Agreed. This would make the GHL inbound webhook so much more useful. I would transfer out of Make if that was the case.
I
Indigo Grady
Ran into a slack integration issue with this exact problem :(
E
Ed Preble
Often third parties who are sending data to my webhooks are looking for a response and I'm unable to provide them one unless I use Make which in turn causes me to use them for other stuff that should be done in GHL. I'd rather stay on one platform.
D
Donald Moore
For example, in Make you can respond to an inbound webhook after processing some data. Since we can now store webhook responses in Workflows (https://www.loom.com/share/263fe3fbc175464aab9b9d8a5fc84659?sid=20f4a154-53fc-4594-8ffb-c7444674595c), this would basically make HighLevel a headless CRM.
Photo Viewer
View photos in a modal