Understanding HubSpot's Webhooks

Welcome to this month developer hug and today we are gonna dive into a super amazing topic, the webhooks. And before we start as usual, a few notes beforehand. So if you're interested in speaking at ADHAG in the future, visit developer-hack.com speak and fill out the form and we will get in contact with you. And just a short outline. The next event will be about GraphQL with the amazing Kata and it will take place on the 25th of July.

So.

This time we have another special and it will be an Inbound special which will be called Roto Inbound and we will be co hosting it with Jennifer Nixon's Huck and it will take place on the 29th of August. So right before Inbound. And if you are not familiar with her hug, we will be dropping the link to that in the chat in a few seconds. And big news, thanks to Tune and SJ Morris, we now have a DHUG community Slack channel. So if you are in the developer or HubSpot developer Slack, feel free to join and have a chat with us. We will post some news, some insights and yeah, so this out of the way today's speakers we have the incredible Chris Bryant from Bryant Works, we have Thun Rutten, lead developer at Bright Digital and of course Angus Gibbs, the engineering lead from HubSpot. The agenda for today is going to be Changelog updates with Dennis. After that Thune will dive into setting up private apps and webhooks. So very important thing, if you are just getting started and want to know how to set up webhooks, then Chris will show us a few examples of webhooks in workflows. And after that, Angus will be covering a bit of what's coming next with webhooks. And last but not least, we might have some time left for Q and A. So if you have questions, drop them in the chat and I will give it up to Dennis. So hello.

Hello. Thank you so much Anton. Let me get my screen up there. I am not going to take a long time doing this because there's so much cool stuff happening that you don't want to see my face too long anyway. All right, so what's happening happening in the HubSpot developer world? First of all, if you have not already, please do go ahead and subscribe to the Changelog where we post all the important things for you. Coming up next, let's go ahead and get on this actual slide. We got a new CTA API. Yeah. You can add this to your, your spa apps, your Single page applications and this just came out I think two days ago. So these links down here are to the documentation. Go check it out. It's really cool. Big note here that this only works with the new editor, not the legacy cta. So check that out. Moving on. I'm not going to go too much into detail here because we have someone who is much more experienced in this than I am, but there is a new Automations API beta out there. It's really cool. I suggest checking this out as well, but do be aware that there are going to be changes to it. It's still influx moving. It's a beta, so be aware of that. But Angus can go more detail about that altogether. Next up, I do want to promote something's really freaking cool which is coding with John. If you don't know John McLaren, he is a developer advocate at the HubSpot. I work with them. I'm very happy to work with him. And he's every Friday for the last three Fridays I think it is, has been coding the new homepage for the developer site, which has been really cool to watch. And last week, if you weren't there, Anton actually made a guest appearance there because he was inspired and made a module that we're going to put on the homepage. It actually converts text to Morse code. So yeah, really cool. And I agree DJ Solaris should make an appearance at some point in time there as well. And that's all I'm going to talk about. I'm going to turn it over to Tune, who is going to tell you all kinds of amazing things. Take it away my friend.

Have fun.

Thank you, Dennis. Well, before we start diving in how to set up webhooks, we probably should discuss what a webhook is first. And it is quite simple because webhooks are essentially automated messages sent from one system to another whenever an event is occurring. And what event is going to trigger that automated message is depending on how you set up your webhooks. So let's take a look at how you can create webhooks through a private app. But the process is quite similar for public apps as well. Now I'm in a portal that I use quite a lot for demonstrations and you can see that I have quite a few old private apps available as well. But in this case I'm going to create a new private app. I'm going to give it a very descriptive name and I'm going to navigate to the scopes. Now, one thing that you have to keep in mind when you are setting up webhooks is that if you want to use webhook events for a specific object, make sure that you include the scope for that object as well. Now, for this demo, I'm only going to use the Contacts object and I'm going to give my private app a few scopes and I'm going to navigate over to the webhook step, because this is where all the magic is going to happen. What I'm going to do is I'm going to use a really nice little website that is webhook site that allows you to test incoming messages that can be sent either through Postman or through webhooks, such as available in HubSpot. Now, what you do is you copy the webhook URL that is available right here. It's quite annoying to open, and I'm going to paste that as my target URL in my new private app. The thing that you have to keep in mind is that you can only define a single endpoint for all the subscriptions that you are going to create in your private app, but we'll discuss that in a minute. So what I have right now is a webhook set up with a target URL pointing to my webhook testing website. One of other settings that is available is the event throttling. And event throttling is going to determine how many requests HubSpot will try sending at once. That doesn't mean that that will only be a single event that is happening in HubSpot, but it will be a single request. Each request can contain multiple events, but I'll show you how that works in a minute or so. I'm going to set it to one for this demo and I'm going to create a subscription. Now, when you click on that button, you get a nice little UI component where you can select the object types that you want to listen for. And if we scroll through this overview, you can see that there are quite a few objects available. I'm going with the contact object, and then I have to determine which events I'm going to listen for. Now, if we go over the options here, you can see that we can listen for events when a contact is created, when a contact is deleted, when a property has changed for one of our contacts, when two contacts are merged together, when a contact has been restored, when an association has changed between a contact and a different object, or when a contact is deleted for privacy. So. So quite a few different options. I'm going to create a subscription for created contacts and for property changed. And whenever I select this specific option, I can define the properties that I want to listen for as well. And this is quite handy because this allows you to set up a subscription for only a few properties instead of having to listen for all all property changes. Now I'm going to listen for a few simple properties in this case. So I'm going with first name and last name and then I'm going to subscribe. Now you can see that I have a new little overview of all the subscriptions that I have defined for my private app. And the great thing is that these are bundled for each object. So if you create company subscriptions as well, those will be in their own little overview, allowing to collapse them for a quicker overview itself. Now, if I want to test my new subscriptions, I have to create my app first. So let's do that. And I'm going to continue creating it. I'm not going to show you the private app token that is created, but what I will show you is what we have available under the AUTH tab. Now, I have my access token available, but I also have a client secret available, and the client secret, as the description is stating, can be used for signature validation. Now this is a really powerful tool that you can use whenever you are receiving webhooks, because this combined with all the data that a webhook is sending, is going to allow you to verify if a webhook event, an incoming request, is coming from HubSpot. I'll show you how you can verify that in a few minutes. Now, if we navigate back to my webhook step and I would click on the view details of one of my subscriptions, you can see that a sample event payload is available. And let's go over the data that is being sent from the webhook subscription. Now, the first thing you can see is that I have an App ID available and the app ID is the app of my new created private app. I also have an event ID which is quite nice if you want to store all your events in an external database to handle them one by one. I have a subscription ID that is going to point to this specific event. So whenever a new contact is created, I have a portal ID available. And this is really nice if you're working with public apps, you'll get a timestamp when the event was triggered. So when the contact was created or when the property was changed. We have a subscription type and this is really nice if you want to filter out specific events incoming to your endpoint. We have an attempt number. And let's discuss this specific point first. Now what HubSpot will do. And you might notice if you are using custom code actions in your workflow, if you use webhooks in your workflows, or if you have set up webhooks before. Whenever HubSpot is sending an outgoing request and if it isn't getting the expected 200 response, it will retry to send the event until it gets a valid response. So this is quite nice. If you have an integration or automation system that won't be able to handle all the events at once, hubspool will start retrying until one of the events has succeeded. Until it gets a valid response, we get the object id and this is the one that I'm using the most because this is the record ID of the object. So in my case the contact that has triggered the event. And we also have the change source. Now this is a really nice one because a few months back I created an integration between two systems using webhooks and I had automations in place for both systems. Now what was happening? My event was sent from HubSpot whenever a property was changed and I was updating the other system through an API call. But that API call, that update, was triggering another automation that was sent back to my integration as well. So it was then creating a loop between events where updates were happening indefinitely. But by using the change source you can see what has triggered the update and by doing so you can filter out any of the change sources that you do not want to handle in your automation. Now the change flag is going to show you if it has been an update or that it is a new record, et cetera. Now, at the bottom of my details you can also see that I have the option to test a subscription and this is going to use the dummy event payload and send it to the webhook endpoint that you have defined in your private app. So let's see what is going to happen. If I click on this button I get a nice little success message with a status code 200 and if I navigate back to my website you can see that there is a new post request coming in from HubSpot. You can see that my sample body is available here as well. And the first thing you might notice is that body isn't an object, but it is an array. And that is because in A single request HubSpot will send multiple events if they are happening. And I'll show you an example in a bit. What we also see is that we have quite a few headers, and one of the headers that we have available is a X HubSpot signature. And the X HubSpot signature header is going to allow you to verify if a request is incoming from HubSpot. My advice would be to use the V3 version of the signature, because that is the most secure one at this moment of time.

Time.

Now, my private app has been published and my webhook is available. So let's see what is going to happen when I create a new record. I'm going with Dennis. 1, 2, 3 upspot.com not sure if that email is valid or not. I'm going to paste in some additional information and I'm going to create my new contact. Now, you can see that again, a little notification that a new event has been sent to my endpoint. If I navigate back, you can see that I have a new incoming body, a new incoming post request. Now, if we look at the body of this incoming request, you can see that my array has multiple events now, and that is because my private app, webhook has a subscription for a contact created a property changed for both last name and first name. And this is something that you have to keep in mind because if you are receiving multiple events, those can be for the same record. But by using the occurred at timestamp, which is the same for all three objects in this array, and combining that with the object id, you might be able to filter out if multiple events are incoming for the same record. If we navigate back to my private app, you can also see that I have a. And I'm using the wrong route there. This is the better one. And I scroll down, you can see that I have a different webhook available as well. Now, this webhook is pointing to a demo application, a node JS application that I have set up for this specific graphic demo, because this is the developer hub. So we do want to see a bit of code as well. Now let's take a quick look at my code. What I have done is I have created a simple Node JS application and I'm using Express to expose several endpoints. I'm using the router that is available in Express as well, and I am creating a route specifically for HubSpot. And if we take a look at those routes, you can see that I'm able to receive incoming post requests on this specific endpoint. Now, if we take a look at my perfect app, you can see that it is pointing to that webhook as well. I have a subscription again, for the contact object with first name, last name, association changed. And whenever a contact is created, and you can see that the first thing that I'm doing is verifying the signature of the incoming request. If we look at my code in the verify signature, you can see that I'm using different variables that are available either in the body or in the headers of the incoming request. I'm using a crypto library, and what I'm doing is I'm retrieving the timestamp, the signature available in the header. I'm using the request body that is being sent. So that's this one, for example. I'm using the request method and the request uri and I'm combining all that information in a new concatenation, creating a hash using the client secret that I have available right here, right here, this one. And I'm going to compare that with the data that is coming in. And if that data is valid, then I know that I can proceed to handle this incoming request. If not, something is probably wrong and you should reject that incoming request. Now, what I'm doing is if my code is verified, I'm going to retrieve the events, which is an array from my body. And in this case I'm using a really simple code, but you should probably filter out everything that you want from that array to determine how you should handle those events. But in my case, I'm simply filtering out the contact events by looking at the subscription type, and I'm going to handle each of those contact events one by one. At least that will be not the nicest ways, but I'm a bit lazy, so I'm simply retrieving the first event that is available in my array and I'm going to do something to that contact. Now, if you remember correctly, I just created a new contact called Dennis, and there is something wrong with my first name and last name. I think I might have given Dennis access to my repo because this shouldn't be happening. But let's see what's going to happen if I were to update another contact. I'm going to update the first name. I'm going to check my logs. Yeah, we have an incoming event and I'm refreshing the page and there it is. My first name and last name are being updated through my code simply because of a incoming webhook. And in this case we have a update contact friction, where I'm sending a bit of dummy data back to HubSpot. Now, this is quite a stupid example because that isn't a really nice user use case. However, using these webhooks you could automate a lot depending on the subscriptions that you have created. You could create new automations whenever an association has changed, you could create automations whenever a property has been updated, when contact are merged, and all of the different subscriptions that I showed you at the beginning of the session. So there is a lot of cool stuff that you can do with either private app webhooks or public app webhooks. Now I'm going to hand it over to Chris who is going to show you how you can leverage webhooks in workflows, because that is another amazing thing that you can do.

Thank you very much. I've got a couple scenarios planned here for us to talk about some of the flexibility of both posting to webhooks via workflows and also catching webhooks via some of the new enrollment triggers inside of workflows. So one of the first examples I have here is HubSpot has leaned heavily into a lot of the AI features that we've seen. But one of the scenarios that we have right now that HubSpot hasn't yet encompassed is the ability to maybe summarize incoming emails so we can triage tickets faster. So what I've done here is I've got a sample email here posted by our good friend Dennis on LinkedIn earlier today where hey, did you know about this thing that's coming up now? I've got another workflow over here that says when a ticket is created, I post out to a particular webhook. Now I'm posting to zap here in this case because I've actually built just a test zap here that catches a webhook, summarizes that text inside of ChatGPT and then posts back a note on that ticket. So that way your end users, or maybe if it's you who's triaging these, can quickly look at these notes as tickets are created and select summarize who is best capable to work on this ChatGPT. You know, you could summarize a sentiment or any other kind of categories or things like that as well to like automatically do triage. But let's give this a shot. So I'm going to come back over here to the inbox and I'm just going to click on this create a ticket button. A lot of times people automatically have tickets created for every conversation, but I wanted you to see this here. Note that on emails, the body of the email automatically comes inside of the ticket description itself. So we're going to create this and here in a moment, if I take a look at this particular ticket, we will get a note tagged up here at the very top. So we just came into here, it's just completed this. I've got some other things in here, but let's go to the note. There's the note from ChatGPT. The D Hug is hosting a session on webhooks with Tune discussing webhooks for apps. Chris Bryant talking about webhooks and workflows and Angus presenting upcoming automations at HubSpot. Anton is hosting event link for sign up program provided. Great. If this was maybe like a help desk ticket or something like that, you might be able to take this and triage this to a particular user. Or if you know somebody doesn't want to read this whole big long post in here because it did add in the the hrefs. So this is hard to read, right? But this is super simple to read and it was near instant in being able to create this quick summary from Chat GPT using zapier. Now another scenario that I often come up with and yeah, that's, that's a great note, Chad just mentioned today was also announced that zapier just got support for custom objects. So this actually becomes even more powerful if you are hooking into custom objects with zapier as well. Now another scenario that often happens. I am a HubSpot partner and many times I am working with clients who have a lot of different systems. Some of these are legacy systems, some of these are systems that we cannot get off of of we have to retain those systems. And I myself use a contracting system that doesn't integrate with HubSpot. So what I've done in the meantime is I actually have a couple workflows to help me kind of get around some of those quirks of my system. So inside my contracting system I have a webhook set up because my one contracting platform doesn't integrate with HubSpot but it does have the ability to post to webhooks. So using the new workflow enrollment triggers that we've got over here, when you create new workflows you can use and create webhooks. Now what I'm going to do is I'm going to go back to workflows here and I'm going to create a new workflow really quick and we're going to use a new contact based workflow and we're going to go next. And in the enrollment triggers, if I click up Here I can now catch when a webhook is received. So inside of this I've got a couple webhooks already created. But the process of creating one in HubSpot is very simple. You just click on the Create a webhook event, give it a very descriptive name. I'm going to call it Catch me. For the purpose of this demonstration, I'm going to hit next and then now I have a webhook. So from this webhook all I need to do is in my case I use a system called Bonsai. I post to that webhook inside of zapier. Now going back to my workflow. Once I posted to that as a test at a zapier. If you're not familiar with zapier, you can come over here. I'm going to edit this really quick edit this existing draft. I'm going to come back over here, grab this because I don't remember if I did or not. We're going to jump back into zapier and I'm going to post up here at the very top and click off this, scroll to the bottom, hit the continue and retest that step. Now back in my workflow test event received and great, there is my web hook. I'm sending over just very basic information. I hit next and now I need to go through and map those different values inside that JSON payload to say this field is this and that field is that. One thing to note inside of this is you must have either the email address or the record ID. Keep in mind, record IDs are only going to be possible if these contacts already exist inside of HubSpot. So right now I'm going to map both of these over here as a text and we're going to hit next and we're going to click on email. Map it over to email. Keep in mind, you could use the record ID if you know that I'm going to hit next again, going to get a big green check mark and then continue to my trigger setup. Now I've already got my one workflow here created, so we're going to use the Catch me. I'm going to click on that. And then in this case I do want to turn on re enrollment because I want this to happen every time this webhook gets captured. For the emails that come in, I'm going to save this. And now we're going to say has completed Catch me. Now in my case, this workflow is dedicated for somebody viewing a contract. So I want to know when they view My contract I have some, I have a lot of different terms and conditions and many different kinds of projects that I use it for and a lot of templates made and I don't really feel like creating all those over again. So I want to view when somebody trigger or when I want to get a ping on Slack rather when somebody looks at a conference. So I'm going to hit this plus button here. We are going to click on communications and I'm going to scroll down here or actually yeah, there it is. Send a Slack notification. I'm going to pick myself because these are all Slack users. Where am I, Chris? Then I'm going to start typing in my message. Now to use the attributes inside of the web hook, you'll click up here at the top and then you can look at those trigger event properties. This should be somewhat familiar for those of you who are used to editing the available data to look across objects or using action properties if you're catching something that happened earlier inside the workflow. So I'm going to say catch me and we're going to say company name or we're going to actually say this email address at company name. Just looked at the contract and we'll hit save. Now in addition to this, if, let's say for example I have a webhook that is maybe capturing information that's already not known on that record inside of HubSpot you can of course use those CRM copy property value actions up here at the top we're going to click on this. From this I'm going to grab the company and maybe I want to copy this down to the company name. So now in the same breadth of catching that webhook I am copying the company out of that webhook to the contact's company name and then also sending myself a Slack notification when that occurs. Now the last scenario I'm going to share with you is a semi complex scenario. Now in this one here I've got two separate HubSpot accounts but maybe I am working with two. I am the same organization but I have many business units within my organization and I have the need to separate my database because I have teams who cannot see what other teams are working on. Very common in commission based structures or if you don't necessarily want to like share leads across different organizations until that time is applicable. Now I've got two HubSpot instances here. I've got a webhooks test one and a webhooks test two. What I'm doing and you can see that these email addresses are pretty well, they're the same across the different organizations. But what I've done inside my workflows is I've got catching opportunities from Test 1 and sending opportunities or sorry, catching them from Test 2 and sending them from Test 2. That's in my Test 1 and this is going to get a little confusing. But in the other account I have catching opportunities from Test 1 and then this is mislabeled. It should be called sending testing opportunity or sending ops to test two. Now what I've done inside these workflows is pretty simple. Inside the send box, I'm merely saying when a contact has a lifecycle stage updated, we post to a webhook which the other HubSpot account catches. Now if I over here to this, inside this account, I'm just going to toggle some of these over here to opportunity and we're going to actually toggle all of them to opportunity. I'm going to hit save and then in a moment I have some fields Test 2, Test 2, Test 2 that my Test 2 account pushes back to my Test 1 account to say, hey, we also have that contact. Here's when we created it. Keep in mind the webhooks function does not allow for date fields or date time fields. It's booleans text and numbers. I believe this whenever it pops over will be stored in milliseconds. I do have a custom coded action here that rewrites those milliseconds into a different create date. And I also pass back over the record ID in that same breadth. I also check hey, was Chris1 created first in this account or the other account? Because that determines is this particular contact eligible for commission. So it's beneficial if you have maybe many different HubSpot accounts and you're working across different business units. You have teams who cannot see what the other people are working on or you have, you know, hey, first come, first serves gets the commission. There's no reoccurring commission, stuff like that. This is a decent way, especially if you're working in multiple HubSpot accounts, to send information back and forth between the different accounts. One caveat here is the contacts do need to exist in the other account at the moment. But I believe Angus has an exciting update on that one coming up after me. But if I give this a quick little refresh, we should hopefully see a test to create date. There's my test one, Test two Record id. So if I needed to, if I'm the well, typically the person doing this work is Normally, the admin, they could look at these IDs, click to them inside the other account. You could also probably get really fancy in converting this to a URL, so you could just click it and it takes you to the record inside the other account as well. But in my Test 2 account, if I give this a quick little refresh, there's my test one create dates because it wrote back, hey, we also have that contact. Here's when they were created. There's their test one record IDs, and then actually it says, unfortunately, all these contacts are not eligible for Commission inside of Test 2 because they are already claimed inside of Test 1 because their create date was before these dates inside of Test 1. So I hope this gives you a couple examples of like, really simple things that you can do really fast to add value using webhooks inside of HubSpot, but also some of these more complex items that you can use webhooks inside of Workflows. So with that, I'm going to hand it over to Angus to wrap us up. Cool.

All right, thank you, Chris, and thank you, June. Hello everyone, my name is Angus. It's good to see you all here. I'm an engineering lead at HubSpot and I'm here to talk a little bit about the kind of future of automation, the future of webhooks at HubSpot. As I said, I'm an engineering lead. I've been at HubSpot for about six years. I have been in the automation group the whole time. Been working on all sorts of things related to workflows. If anyone has used the Custom Actions API, I was involved in both the V1 and the V4 versions of that. For better or for worse. If you have questions coming out of this, I am Angus in the developer slack and I'm agibbsostbot.com if you want to shoot me an email. Always happy to get questions, get feedback.

Cool.

For the future. Before I actually talk about the future, I thought it actually might be interesting to get a little bit of background on the history of automation at Hubblespot. So the background here is that back in 2014 is when the Workflows app was first introduced at HubSpot. 2016 was somewhere around 2016. I can get the exact date was when we released our first public API. 2018 was when we released the first custom actions API. These are all things that I'll explain what some of these things are. If you're not familiar with custom actions and stuff like that, the Workflows app was originally this marketing contact focused tool. And 2019 was the first time that we had non contact workflows. You could start to automate things other than a contact. In 2020 we relaunched the custom actions API. And then 2021 was a big year where we launched Operations Hub at the HubSpot level that had some new features in automation. And that was kind of a shift for us to start to look at some of these operation focused, not be so marketing heavy as a tool. And one of the results of that was what Chris just showed off. Webhook Triggers, which got launched last year. Quick disclaimer before I talk about some of this stuff. Nothing I'm talking about here is a promise that we're going to do anything except for the things that are already in beta. Team roadmaps and priorities can change. And actually I want to hear from all of you about what webhook or automation features you'd like to see. That's really helpful for us to have use cases, engage interest. So my contact info is in the bottom left there as we go through this. Definitely want to hear from y'.

All.

Okay, first thing, right off the bat, this is only kind of tangentially related to webhooks, but I wanted to call it out. Dennis mentioned it too, but we have a new Flows API. Super excited about this. If you want to programmatically create workflows, you can do that now. This is now in public beta as of a couple weeks ago. It is much better than our existing API. We know that the existing one is not good, but the new one is much better. It works in all object types, not just contacts, and it also supports all types of actions. Every workflow feature, anything you can build in the app, you can build on this API. Already seen a lot of really cool use cases come out for that. Definitely look at that if you're interested in that kind of thing. Custom actions, this is webhooks, though it's not as obvious. Custom actions are a tool or system that we have at HubSpot for packaging up a webhook and just abstracting away the fact that it is a webhook from people. So if you want to build something that's a reusable webhook action inside of a workflow that allows some configuration that has input fields that somebody can go out and configure how the action works, that's what custom actions are good for. They're tied to an app. It can be a private app or a public app. And they are also good for if you want to have a webhook that's shared across multiple portals because they can get installed as an app. A couple of things that we're looking at on the custom action side. One is local development. If anyone here uses the CMS to develop things that you can develop locally and then use the HubSpot CLI to push the changes up. That's something that we're looking into for custom actions to be able to manage those more easily and to deploy them more easily. In general, we're looking at all sorts of things to make it easier to build, manage, test and deploy custom actions. I also just wanted to call a couple of existing features which I think are in some places underutilized. If you have any need to do anything that spans multiple locales, like you have clients in multiple countries, you can actually provide translated labels to your custom actions. That's really handy. Then also, if you have certain cases that your action might fail or the webhook might produce an error response, you can actually add custom action log messages. There's info in the custom action docs on how to do this, but this can be really helpful so that you don't have somebody calling you up trying to ask why something's not working. You can give them a message in the workflows app explaining why it didn't work. Webhook trigger is cool. We just got a great demo on this from Chris. Right now the support in non contact workflows is pretty minimal. I think you have to match by your record id. We're looking into other ways to match on those object types. Actually would be interested to hear people's non contact use cases. Webhook triggers. Another bigger thing that we're looking into is being able to actually use a webpage trigger to trigger a workflow without an object at all. And that might be useful in cases where you actually the goal of the workflow is to create an object. So that's kind of getting looked into right now. We also want to expand what you can how you can use the data from the webhook. You can actually add tokens into your actions that reference some of the data that came in as the webhook. But we wanted to just make that more powerful, bring it into more places. A recent change we made on this front was actually letting you do branch operations other than equals on data from a webhook. So you can now if you have a webhook that includes a score or some sort of number, you can do a greater than less than comparison. So that Seem small but actually unlocked. Some pretty cool use cases there. Yeah. And this is the last thing that I wanted to talk about. This doesn't exist yet. This is actually something that we're kind of still in the research phase for. So definitely really looking for feedback and use cases on this one. Kind of similar to how we have the webhook action workflows which is very low level. It's very in your face that it's making a leopard call versus custom actions are abstracting that away. We have webhook triggers which are again very interface. It's like webhooks. It's very customizable but not super reusable and a little bit scary to use sometimes. Custom triggers is an idea that we could give a similar packaging experience where you could build. Think about the fact that it's a webhook trigger so much. This is something that we're exploring. There's a bunch of different directions we go with this. I know that some other tools do this in different ways. So if you have ideas and if this is something that you're interested in, definitely, please reach out to me in the developer Slack Angus or an email. We'd love to hear any ideas you have. I think that's it. Thank you all. I think that we have some time for Q and A, so I'll let Dennis come back on and we can take any questions.

Thank you. And maybe I'll bring tune on here if I can find them. There you are. Cool. Thank you. Thank you everyone. This is really, really, really cool stuff. I do highly encourage every single one of you to flood Angus's inbox with all types of ideas right now after this presentation. All right, let's talk about some questions. There have been a couple. If you have any, please do me a favor and throw them in there so we can answer them for you. Estron did ask catching external webhooks. I know that Nick, I think answered this, but I do actually believe this is possible with CMS serverless functions. But it's not advisable because there are some limits. There are stricter limits on the uses for serverless functions. You will probably hit those very quickly if you were to throw a whole bunch of webhooks at it. I asked someone internally while we were doing this to confirm and that's what he told me. It's law at this point. Nicola said if we receive an event through a web, can we use that data later to create a custom action without using custom coded actions? It's a curious question, Angus. I'll let you decipher for me, if you don't mind.

Create a custom action that you think you can create a. So the custom action you configure independently, that's something that you set up once and then you reuse multiple times across your workflow. You can definitely have a webhook trigger that one of the actions is a custom action and you can use data from that webhook trigger in the custom action. But in terms of your reason, you. Yeah, I'm not 100% sure if I answered that the way you want. Definitely feel free to.

Yeah, maybe. Maybe some more details on the question would be helpful for this one because I'm not fully there either. I'm not seeing any other questions in the Q and A. If there are none, I will allow everyone 12 minutes. 15 minutes left here, so, you know, we can get out of here early. But if there's any more questions, go and throw them in there. I do want to say thank you again to all the presenters today. Angus, some really cool stuff coming up. Tune. Thank you. Seriously, through just verification of signatures is something that we don't think about enough and we don't document enough, like as tutorials. So thank you for doing that. That was really good. Chris. Use cases. Amazing stuff. And I do want to once again promote tomorrow at 12:30pm Eastern, I think it is John McLaren will be coding live a website which I wholeheartedly think you all should be there and watching. Do you all have anything to say other than what we got? Otherwise, I want to say we're done.

Thank you all.

Cool.

Thank you.

All right, get out here. Y' all have a good day.

Thanks.