This site has been archived. Please visit for our new support documentation and contact information.

Distinguishing between client updates and API updates

Jake Krohn's Avatar

Jake Krohn

03 Jun, 2014 03:28 PM

I am developing a custom webhook to allow for more in-depth error checking and email notifications based on certain criteria contained within the submitted data. Based on the result of the checks run within my webhook endpoint, I would like to update the status of the record. However, doing so triggers another "record.update" webhook request, and so on.

Am I missing anything obvious that would indicate the source of the event that triggered the webhook request? Something like a "source" attribute in the payload that is sent to the endpoint with values like "web", "api", "client" would be useful in this case.

Short of this, I am planning on implementing a transaction tracking process whereby I log the initial transaction ID of the webhook event raised by the client, set a "Last transaction ID" field in the form along with the status change that I want to do, then issue an update through the API. I should then be able to get back the same transaction ID from the second webhook event that is fired, recognize it as part of the original transaction, and exit the webhook script early before continuing on with the rest of the processing that usually occurs with a client-driven update. I'd rather not do that extra work or add extra fields (even as read-only or hidden fields) to support this kind of functionality, but it appears to be my only option?

  1. 1 Posted by Kyle Tolle on 03 Jun, 2014 06:14 PM

    Kyle Tolle's Avatar

    Hi Jake,

    I think there are a couple other means that won't require the kind of effort that you had mentioned.

    You could add an additional check that won't update the record if the status is already set to the value you would set it to. This would allow your webhook to work nearly identically as it does now. It would still receive the extra webhook event from your initial update, but your webhook would realize it doesn't need to update a second time, and effectively short circuit itself.

    Another method would be to store the record data that you process. After you perform your initial update, you could locally save the record data returned as the response to the PUT. Then when the next webhook comes in, you check to see if the record delivered in the webhook event is exactly the same as the record you saved off. If it's the same, there's no need to process it. This would be a bit more effort than the above one, but it's something to consider.

    Do either of these ideas seem feasible? They don't require you to change anything about your form's structure or add anything additional to the record data, which are the main benefits. They do require something additional on your end, but this seems like the right approach since it's business logic being built on top of the core webhooks functionality.

    The source for the changes to the record is an interesting idea though, so I'll be sure to make a note of it so we can evaluate that option/idea in the future.

    Let me know if we can help with anything else.


  2. 2 Posted by Jake Krohn on 03 Jun, 2014 07:52 PM

    Jake Krohn's Avatar

    Good ideas; thanks.

  3. 3 Posted by Kyle Tolle on 03 Jun, 2014 08:01 PM

    Kyle Tolle's Avatar

    Glad I could help.

    Additionally, the response to a POST or PUT returns the record data which includes the version attribute. You could store the record's id and version number. That should be sufficient to allow your webhook to know it doesn't need to process that webhook event. This would require less space than storing the entire record payload.


  4. Jake Krohn closed this discussion on 17 Dec, 2014 04:46 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac