Yes. This is what I see. I think it’s to be expected. But annoying nevertheless.
Adding @Fuchs which I developed the app for his company.
Can you share the data of the tracking on the webhook send and mis sending in the plant doctor?
I’ll prepare a video and will send you tomorrow including support link.
On one of my webhooks basically the user email address is not called at all as well as the user ID
I can attest to this statement. My primary use case is payments. Send webhook > update spreadsheet is near instant. However, the update to Glide can take upwards of 5 min (even if pro and update if when using app).
With verification of payments, it needs to be instant.
I second that as I actually opened a feature request for it here to atleast respond back by response to glide or even into google sheet via glide for the instance response
yeah, same. I use lots of webhooks and have never had a problem with them not being sent. Maybe I’m just lucky
we need direct subscription from glide to stripe maybe that would fix the timing
This would be even easier if glide could handle the webhook response. So you can send a json object back to glide and process it in the same action.
I recently made a similar request.
A json column would also be nice. I mean combine multuple columns to a valid json object and generate a json array out of a relation.
It’s an interesting thread.
As I see it, webhooks in Glide are currently “fire and forget”. This makes them fantastic for pushing data somewhere outside of Glide and / or starting some external process. They are not currently designed to wait for the “recipient” to do something and report back. That would be closer in functionality to a REST API call. The latter would be incredible for sure, but it would either require (a) the app stalls whilst waiting for the response or (b) the app gets a trigger when the response is received at some point in the future. Neither currently fit with the Glide model but the first is probably easier to implement (just guessing).
The Integromat webhook scenario is a case in point. It’s fantastically useful to hit Integromat with a webhook, but the app does not hang around for a response, despite the fact that Integromat is capable of sending one. So if your Integromat scenario takes 4 or 5 secs to run, the app has already moved on. This means that (AFAIK) the only way to get any feedback into Glide is via a Google Sheet update from Integromat once its scenario is complete (success or failure). Of course Glide may then take “some time” to reflect this sheet update back into the app.
I would love to hear any thoughts from the Glide team about future intentions in this respect, even if just a staged approach in the first instance to somehow accelerate the updates back into the app via a Google Sheet.
Just to complete your comments on the return of a Webhook action:
I quote Mark:
The response body is ignored, but HTTP status codes are honored. HTTP 2xx is treated as success, HTTP 3xx is honored and tracked, and all other states, including socket connection failures, are treated as failures and are eligible for retrying.
Hrm? Are you sure that’s not related to the API column that the guys were testing a while back? If this does relate to Glide webhooks then I don’t see how the app gets any visibility of the status code returned?
This is Webhook Action.
Here is the full message on the subject
And the tests I have done confirm that if the return is not correct, Glide repeats the Webhook action
Yes, however I think the status codes determine Glide’s internal approach to retrying the webhook. Glide webhooks are not called from our apps. Rather, the app instructs the Glide “backend” to call the webhook on its behalf. So the status codes are available to the Glide “backend” but not to the app. Hence the app cannot know the outcome (at this time). If you have a way of determining this in your apps then I’d love to know because it would be amazing
That’s right, well, it’s also my deductions.
No, I don’t have a solution to offer you, I’m a bit like everyone else, waiting for an evolution.