Delay webhook until previous webhook server response

Get Help
, , , ,
1

Hello,
I want to experiment with 2 webhooks. First webhook is sent when form A is submitted, then the second webhook is sent when form B is submitted. However, I want to test sending form B’s webhook not on form B submit, but instead when I get a server response from form A’s webhook.

If I have a php function to capture the external server’s response from form A’s webhook, what would be the recommended way to then trigger form B’s webhook to send based on that response? I should point out, it is highly possible we will already have the response from form A before the user submits form B, but it has caused us problems during testing so I’d like to eliminate the possibility of the receiving server getting form B’s webhook before form A’s webhook.

I looked through the docs on the form object and entry object, and I found this " gform_post_process_feed," but I feel like I would need something that ran before the feed was processed.

Thanks.

2

How about if you submit form B when form A webhook returns? Then, form B webhook will run after submission.

To do that, you can tie GFAPI::submit_form to gform_webhooks_post_request:

Will that work for you?

3

Hello Chris, thank you for your response. The above could possibly be a solution; however, the website in question is a membership portal that will have a 2-part membership signup for multiple organizations. How many orgs I’m not sure at this point, but easily over 10 where each have a form A and a form B.

For your proposed solution, is there a way to pass the form ID as a variable rather than hardcode it? My concern with that would be an ID passed as a variable would run on form A’s submit as well?

Second, I’m confused how using GFAPI::submit_form() would prevent form B from submitting until the webhook response from form A was received. If that method is used with a forms hardcoded ID, as in the example, does that automatically override the submit button on form B from submitting and sending the webhook when the user clicks “submit”? If this were implemented, what happens when the user submits form B, does the form appear to be submitted in real time, but behind the scenes it’s being delayed while waiting for the response?

To walk through your proposed solution, we would use gform_webhooks_post_request to listen/wait for the correct response from the receiving server from form A’s webhook, when that response arrives we then use GFAPI::submit_form() to submit form B?

Just to give more background on the issue at hand, these are two stand-alone forms, form A redirects to B. The receiving database is throwing an error if the form B webhook is received before the form A webhook. I’m not sure how this is possible, because my logs show clearly that form A’s webhook is being sent before form B’s (at least by 7 seconds in a very fast test I ran). When these webhooks hit the receiving server, form A is updating a record and has more fields to check than the form B webhook. I do not have access to the receiving server, but it seems that form A’s webhook takes longer to write/update than form B’s, which is why form B sometimes finishes before form A’s webhook is complete. Everything I’ve read on the topic advises creating a queue on the receiving server side, but the devs on the receiving end don’t want to do that for whatever their reasons are.

Last, at what point would you be concerned about server load and possible data loss on my end if we are delaying a webhook, while other signups continue to come in from email campaigns, etc.?

4

Hi @user648c88d38f0fe544,

This would be an excellent case where Gravity Flow’s extensions can make it a snap to coordinate action and handle responses between forms and webhooks.

The outgoing webhook step in Gravity Flow functions very similar to the Forms webhook addon, with the added ability to map response data from the API back into form entries with field mapping settings. In the event your API had a non-200 response, it also supports being able to send to a different step in the workflow (think conditional logic but for steps as branches in the workflow)

The Incoming Webhook extension can be used to either have the incoming webhook request be the trigger to create a new entry or as a step within the workflow to move things forward. The step type also has an option for expiring to cover the edge case where the API doesn’t reply within a planned amount of time, the entry doesn’t become bottlenecked - you could assign it to someone on your team to investigate/retry/etc.

With the Form Connector extension there are two step types that might be of interest for your use case. The Create an Entry step type would let your Form A entry which has received a webhook response (through the incoming webhook step) create the entry in Form B with as much/little field mapping into the new entry as needed. This would be pretty close in concept to what Chris was suggesting through code.

The other step type from Form Connector which might fit better for you is the form submission step. You can create a link to request that someone create a Form B entry again with field values being pre-populated from the Form A values (including ones the webhook might have provided).

If your use case didn’t have a hard need for the two submission activities being fully separate forms, you could consolidate all the fields into one form, having the ones that were Form B setting their visibility to administrative (not shown on the initial form submission screen), and then use the user input step type to define who (assignee) needs to see (display fields) or submit (editable fields) as a part of their task.

Cheers,
Jamie

5

Thanks Jamie, still hoping for a response addressing my questions above.

6

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