Skip to main content

Webhook gets triggered on every character entered in a field

E

I have a webhook set up where it is watching single field in one table. The issue is that the webhook gets triggered on every single character entered/deleted. The expected default behavior is that the webhook gets only triggered when the user is done with the input.

So if text 123 is entered into the input field, 3 separate notifications are sent. I would expect to receive only one notification when user enter a value and the field is deselected?

Is there an option to enable such behavior using webhooks api?

Webhook creation body:

{ "notificationUrl": "https://webhook.site/4a5fe5f0-7a32-4ba0-bb59-f2acb89c7766", "specification": { "options": { "filters": { "dataTypes": [ "tableData" ], "recordChangeScope": "tbl00000000000000", "watchDataInFieldIds": [ "fld00000000000000" ], "changeTypes": [ "update" ] }, "includes": { "includeCellValuesInFieldIds": [ "fld00000000000000" ] } } } }

 

    4 replies

    B
    • Bill_French
    • Inspiring
    • 3264 replies
    • June 14, 2023

    > ... So if text 123 is entered into the input field, 3 separate notifications are sent. I would expect to receive only one notification when user enter a value and the field is deselected?

    Your expectation is wrong as indicated here. 😉

    E
    • Evaldas
    • Author
    • New Participant
    • 1 reply
    • June 14, 2023
    Bill_French wrote:

    > ... So if text 123 is entered into the input field, 3 separate notifications are sent. I would expect to receive only one notification when user enter a value and the field is deselected?

    Your expectation is wrong as indicated here. 😉


    The expectation is not unreasonable. You can specify which table or even field update should send a notification. It is not unimaginable that you would be able to specify what specific interaction(input in progress, completed input) would send a notification as well. But as far as I understand that is not currently possible.

    Information that would let to identify what interaction happened with the field is also not present in the payloads.

    A workaround would be to check the payloads every x time and if the field was not touched for a while an assumption could be made that input was completed and is ready for processing but again that defeats the purpose of using webhooks.

    B
    • Bill_French
    • Inspiring
    • 3264 replies
    • June 14, 2023
    Evaldas wrote:

    The expectation is not unreasonable. You can specify which table or even field update should send a notification. It is not unimaginable that you would be able to specify what specific interaction(input in progress, completed input) would send a notification as well. But as far as I understand that is not currently possible.

    Information that would let to identify what interaction happened with the field is also not present in the payloads.

    A workaround would be to check the payloads every x time and if the field was not touched for a while an assumption could be made that input was completed and is ready for processing but again that defeats the purpose of using webhooks.


    Upon receipt of a webhook notification, are you calling back to get the changed field value as per the docs?

    And, are you using the prescribed indicator to group all hooks related to one field change?

    Have you looked at returned payload values mightHaveMore and cursor values in the ListWebhooks callback? I use this data to determine the likely state of any field change.

    Webhook systems generally try to shed the intent of users and let developers handle how events are interpreted. Since Airtable uses an optimistic save architecture, there is no concept of a commit. Ergo, events are subject to interpretation. Aitrtable knows that in some use cases, such interpretation can come in dozens of variants, so they’re reluctant to guess what your specific heuristics are.

    I got permission from a client to share this, but not all of it. I'm not sure it's the perfect approach, but it works and it's reliable. The key is to craft a webhook listener that can apply arbitrary logic to know when it needs to push the value in the Airtable field (or record) onto the target waiting for the data. If any payload list for any given even collection is idle for more than 400ms (Doherty's threshold), we assume the entry is complete. If, by chance, it is not, the process begins again and the payload list for this original notification begins again.

    In the worst case, the data sent to the target is incomplete, but only for a few hundred milliseconds. What I did not show is how we use AI in this process to determine the probability the user is still typing. This approach has proven to be extremely accurate. The architecture presented here has been in place for about 20 months I think and working mostly without any drama.

     

     

    B
    • Bill_French
    • Inspiring
    • 3264 replies
    • June 15, 2023
    Bill_French wrote:

    Upon receipt of a webhook notification, are you calling back to get the changed field value as per the docs?

    And, are you using the prescribed indicator to group all hooks related to one field change?

    Have you looked at returned payload values mightHaveMore and cursor values in the ListWebhooks callback? I use this data to determine the likely state of any field change.

    Webhook systems generally try to shed the intent of users and let developers handle how events are interpreted. Since Airtable uses an optimistic save architecture, there is no concept of a commit. Ergo, events are subject to interpretation. Aitrtable knows that in some use cases, such interpretation can come in dozens of variants, so they’re reluctant to guess what your specific heuristics are.

    I got permission from a client to share this, but not all of it. I'm not sure it's the perfect approach, but it works and it's reliable. The key is to craft a webhook listener that can apply arbitrary logic to know when it needs to push the value in the Airtable field (or record) onto the target waiting for the data. If any payload list for any given even collection is idle for more than 400ms (Doherty's threshold), we assume the entry is complete. If, by chance, it is not, the process begins again and the payload list for this original notification begins again.

    In the worst case, the data sent to the target is incomplete, but only for a few hundred milliseconds. What I did not show is how we use AI in this process to determine the probability the user is still typing. This approach has proven to be extremely accurate. The architecture presented here has been in place for about 20 months I think and working mostly without any drama.

     

     


    @Evaldas More insights over there. @kuovonne and @ScottWorld added some excellent thoughts.

    ScottWorld
    1 person likes this
    • ScottWorld
      ScottWorld

    Reply


    Most helpful members this week

    Terms & Conditions