51ºÚÁϲ»´òìÈ

Transcript

Quick intro. So we’ll go into the next slide, Darshan.

Just seeing the first slide still.

Okay. Yeah, we’re going to some intro stuff. You’re able to move it to the next slide. Is that working? Yeah, I’m already on the speaker slide introductions. No, we see just normal PowerPoint, like in the edit mode. No, it doesn’t go into present mode. Okay.

But we can go from there. Thanks, everyone. Hi, John here. Be the moderator for today. So please, as we get started into the session later on, if you have any questions, answers, please add them into the Q&A component, which will enable an old when needed interrupt, Darshan and Josh, as we go through. Quick intro to me. I’m a two-time Marketo champion. I’ve done quite a few 51ºÚÁϲ»´òìÈ certifications, one of them being the Marketo architect. Working at the center. Yeah, been working in the space for, I think, nearly 12 years now. Darshan, if you can give a quick intro yourself. Yeah. Yeah. Thank you so much, John. Hi, everyone. This is Darshan. I work as a senior consultant at Lloyd. I started off my career with Marketo and it’s been good five years. And super passionate about Marketo, marketing automation in general. And I am a two-time Marketo champion and champion of the year 2022. Multiple times certified architect, expert, and I love integrating stuff. Be it custom integrations, be it native integrations. I love managing the Martex tech and ensuring the data flows from one system to another system. In a streamlined manner. Be it using REST APIs, webhooks, everything. So, yeah. Thank you so much for taking the time to join us in our session. And I hope you will find the session insightful. Thank you. Over to you, Josh. Sure. My name is Josh Arrington. I am partner and chief marketing technology officer at Capturo. I’ve also been working with Marketo for 13, almost 14 years. So close to the beginning. Similar to Darshal, I love kind of the outside of the box integrations and solutions. So I work mostly on the technical side with the webhooks, APIs, and more recently self-service flow steps. I’m excited to be here.

Thanks, Josh. Thanks, Darshal. Just a quick agenda for today. So introductions, already done with. I’m going to go through just a few quick housekeeping things for our mug meeting. And then we’ll get on to the content that everyone is here for. Which will be looking at APIs, how they’re different to webhooks. Some of the basics about the webhooks and how to set them up in consideration. And also important topic when we talk webhooks, how we get that access. Some use cases. Some nice things coming there. The tips that Darshal and Josh have come up with over their years of working with webhooks. And also good to be aware of limitations. And then at the end, we’ll have a more dedicated Q&A session. But I have also enabled the Q&A now. So if you have questions as we get to the content of the presentation, please feel free to post your questions there. So first, quickly on to these housekeeping. Again, as you’ve been to any other mug before, same rule applies. But let’s try to keep this user focused and a safe space. So no self-motion in the mugs. We also please don’t contact anyone else that is in attendance without their prior consent to that. And if someone does share a use case or something that’s a bit personal to either the company or the clients that they work with, please don’t share that further without their consent.

This mug is also being recorded. So just to let you know that it will be posted on both the page where you registered for this and the YouTube channel from the Marketer User Groups later on. If you’re not okay with being on the live recording for that, please feel free to leave the meeting now and then find the recording once it’s posted on one of those two locations.

Also, if you want to stay up to date for any more of these deep dive, we’ve got a few more scheduled coming up. I think there’s at least one a month for the rest of the year. Please make sure that you are a member of the 51ºÚÁϲ»´òìÈ Deep Dive mug as well as maybe the local mug or any others that you are subscribed to. That means you’ll get the notification when a new event is posted.

And just some quick other upcoming opportunities. One, there was a webinar last week, I think it was, that talked about how to become an 51ºÚÁϲ»´òìÈ champion. I think we all mentioned in our intro that we are an 51ºÚÁϲ»´òìÈ Marketer Engaged champion this year. It’s how we got invited to present on this topic. So if you’re interested to following in our footsteps, there was a great session presented by the program managers from 51ºÚÁϲ»´òìÈ on this topic last week. It tells you all about the program, what eligibility looks like, what’s involved, what the commitment is from your side. So you can watch that recording here as well or find it on the mug website.

We also had a request from the Adoption and Retention team. They’re looking at some user research to understand better the marketing practitioners and how you use Marketo. What’s working well, what challenges and pain points you’re facing. So two very quick ways that you can interact with that. We’ll put these up again at the end for those that want to focus on the content now. But one is just a quick survey. And the other is if you’d like to have a lot more feedback you might want to share, feel free to also use the other QR code and schedule an interview with the team. And very quickly, looking at some of the other upcoming events that we have today. The one top list is the one we’re at now. But there are a few more North America based events happening. Mostly consider that for a time zone point of view because I think the majority of them are virtual events and you are welcome to attend any event that you are interested in. And we also have a few upcoming outside of North America as well, including I see Zoe joined here, also launching the first ever Irish mug that’s going to happen in May. That’s quite exciting. We’re growing more. And another exciting one for London, which will be hybrid. So you can join in, but it’s going to be a special one with the Masterclass. So Josh will be there. I’ll be there. There will be four or five other champions as well presenting some nice topics. It’s going to be a longer session. Looking forward to that one. But now for what we’re all here for, for the deep dive session, I’ll hand over to Darfel and Josh and we’ll start talking about how to use webbooks for data transfer. Thank you. Thank you so much, John. And yeah, thank you so much again for joining in. We’ll be covering this topic in pretty depth. We’ll be exploring all about webbooks. And why not, when we are starting out webbooks, of course, we’ll be starting from the basics, we’ll understand the use cases, and then we’ll also have some of the short tips and workarounds and some of the technical limitations as we saw in the agenda. But why not start with one of the questions that I get most asked from the users that, what’s the difference between webbooks and API? So let’s probably start debunking that myth. So basically, webbooks are like, they are an entity or they allow you to communicate or make requests from Marketo engaged to an external service. And when we compare it to an API call, API call is something that makes a request to Marketo. So the direction of the call or the request that is made is kind of important. So webbooks, as you can see on the screen, it’s something that is server initiated. So server or the, you know, in this case, Marketo, it is something that is initiating the call to an external service, whereas an API call you see on the screen, it is something that, you know, it is initiated from the client’s end, and it is made to the server. And there are different use cases for each of them, webbook versus API call. But at any point in time, when you differentiate between a webbook call and API call, you can just, you know, imagine and identify the point in direction, the point, the direction in which the data is flowing, and the way that you’re calling, you know, making the call. If it’s originating from the server or like a system or Marketo engaged system, then it’s a webbook call. Or if it’s something that is originating from the client end, and it is going to the server, it’s an API call kind of thing. So webbook allows you to, you know, integrate your services physically. So if you want to pass any outbound data from Marketo to any of your services, you would use a webbook call. And webbook, you will define an API point, like an endpoint and all of the other parameters in your web book call, but the call that you make to that particular service would be via a web book. I’m sorry, if I don’t want to interrupt, can you guys go into presentation mode? It’s kind of small and it’s hard to read. Can you see it now? I think a few. Yeah, okay. Like on the screen, it’s going to the PowerPoint menu and things like that. So if you just enlarge, like go into presentation mode, it would be… Yeah, I can hear the sub-sharing. I’ll try to present from… Yeah, I’ll stop sharing my screen.

And I’ll just add, they are separate webbooks and APIs, but they can be used together as well. So you can trigger a webhook that then calls a service that uses the API to take another action in Marketo. So they can be used in conjunction too. Oh, that’s much better. Yeah. Great. Yeah. Thanks, John. So yeah, I’ll continue. Yeah, but yeah, thank you, Josh, for adding that. And one more distinction is that the webhooks are kind of a stateless entity. So when I say stateless, I mean that data is not preserved from one call to another call. Any data that is being used in a single webhook call and the data that is returned as a response in that particular webhook call remains in its entirety for that particular webhook call. It can, of course, be transitioned to and carried over to a different webhook call. But for that, you need to have some different configuration. It’s stateless compared to an API call. They are like they can you can have statefulness architecture. It’s a possibility you can carry over the response that you got from an API call to a different or a subsequent API call. And there are workarounds when you know, when you can bring in the statefulness in the web calls. But there are certain workarounds and we’ll be discussing those towards the end. And one other parameter is that like the webhook call, it requires a compatible service service that is listening for a webhook call from a server or a system that is a market to engage kind of system. You need to have that already in place. And the another distinction is that the kind of, you know, the kind of activities that you can do from one end to another. So webhooks allows you to transfer or, you know, have certain services performed via a third party services, whereas for an API call, you can post updates. You can create an asset, for example, using the market those asset APIs. You can post the lead update, create a lead, etc. So those are some of the distinctions between webhook call and API call. And I am pretty sure that these distinction will get clearer when we discuss more in depth about webhook. And yeah, in the subsequent slides.

Yeah, so, you know, let’s start with some of the very basic slides, like what is webhook? So when we discuss about webhook, it was the word webhook. It’s composed of like two words, webhook. So it allows you to create. It’s a method through which you can, you know, hook multiple web services together, you can integrate, you can connect the web services together. So, for example, you have your 51ºÚÁϲ»´òìÈ Marketo engage instance, you have another third party service that is performing certain calculation manipulation of the data that is in your 51ºÚÁϲ»´òìÈ Marketo engage. So if you want that service to like if you want to integrate these two platforms, you would make a webhook call and outbound webhook call from Marketo. So, you know, that’s what the basic idea about webhook is. So the core requirement of webhook is that the service must be a web compatible since it’s a web based service. It could be on the HTTP or HTTPS protocol. And so and of course, as I said, it allows you to integrate your 51ºÚÁϲ»´òìÈ Marketo engage and as a matter of fact, any other platform with your third party external services. It allows it opens a wide array of possibilities, for example, data transformation or cross application communication and even advanced calculations which are not possible natively within Marketo engage. For example, up till recently, we were not able to like add scores like you can do so by webhook. There are certain services, webhook services and platforms that allow you to quickly create like using the basic JavaScript based code, you can use that in webhook and perform those external services using those webhook calls. And any other sophisticated data processing that is needed by your use cases that you are not able to do natively within Marketo, you can do so by like facilitated those via the third party services and you can call those third party web services in the webhook call in your market. Yeah, so you know, like, the first question is like how to use a webhook in market. So in order to use the webhook in market, we would want to go to the admin section, then under the integration tab, you would want to select the webhook. And if you are creating a new webhook, you would want to select the new webhook option. And if you are creating a new webhook, you would want to select the new webhook option. And when you select the new webhook option, there are like certain configuration items and new dialog box that opens up. That is in the next slide. Can you move to the next slide? Yeah, thank you. So, you know, this is the dialog box that you will see when you like when you create a new webhook, you would be, of course, asked to enter a webhook name. So any name that closely resonates with the service or with the kind of work that the webhook does, you can name it. And of course, there’s an optional description and then there’s an URL. So this URL would be the point like it will be an endpoint. It will be pointing to the service, third party service to which you want to make a call from this particular webhook call flowstep. And of course, in the subsequent slides, we’ll see that you will call the webhook via flowstep in a campaign. But apart from URL, you would need to also add the payload. This is like if you want to send any outbound data to market with this particular webhook call, you are going to be adding that particular body parameters in the payload. And then you have the request type. Up until recently, there was, you know, like a couple of request types that you can build it on the webhook. But then market recently, not very recently, but yeah, like a couple of years back, they also added a few more service types like request types. So you can now do delete, put, patch, get and post operations using webhook calls. Then, of course, the encoding type, if you are like requiring any JSON or XML encoding type, you’re going to be selecting that. And then the response mappings. So these are the things that we’ll see a little bit in detail in the later slides. But a webhook call, when you make a call, an outbound call from market, that service at some point in time will return certain response parameters. And if you want, you can, you know, map those or use those data that is returned by the service map, those two fields on the person record and those data get saved on the person record. So you can do that in the response mapping. And there are also other optional custom headers that you can configure with the web. So sending data in a way, as Darshav mentioned, for simple requests, you can use a get request and then just pass the parameters in the URL of the webhook. In this case, you can use hard coded values or you can use tokens. When you have more data, it probably makes more sense to use posts or one of the other services available. Typically, get and post are going to be your number one things to use. In this case, you can use JSON or XML. Both are accepted. Actually, I mean, you can pull whatever you want, but those are the typical ones there. In this case, you can use all the tokens you would in for a lead. So you can use all the lead records, lead fields. You can also use program fields, program member fields and program tokens. So the question is where which program are they going to come from? Wherever the webhook is triggered from, it’s going to pull the tokens from there. And you have triggered system tokens available to you as well. So there’s a lot of data that you can pass out of there. And it also gives you the ability to make these very flexible. So say you wanted to send out to a webinar service or some sort of event service and tell it which event someone’s registering for. Instead of having to create multiple webhooks for each event, obviously, that would be too much. You can just pass that as a token from the program or from the program member field, things like that. And then next, obviously, is once you send it out, how do you get the data back? That’s where field mapping, response mapping comes. Here, you can support JSON or XML. There’s no limit on the number of field mappings that you can set up. So even if you have very complex and a large amount of data coming back, you can map all of those. The properties are mapped with the dot notation and array notation. So even if you have nested values in JSON or XML, you can get to them. Here you can see in the highlighted one in orange here, name.lastname. So if you had a name object and underneath it you had last name, you could get to that with name.lastname. And then to get to an array, if you had names, for example, you can use array notation, which is just your brackets, square brackets with the number of the item you get to. You can map to lead fields and also to program member fields. And these updates will only happen if the Webhook service returns a 200 response code. And we’ll get to, later in the presentation, how to detect errors in your response, how to avoid them, and make sure it runs smoothly.

Yeah. Thanks, Josh. I can talk a bit about the authentication with Webhook. So let me start with the very basic. So when you are making a call to a third-party web service, you would want to ensure that not everyone out there can actually make a call next. This will call to that service, otherwise you will get bombarded with a lot of requests. So you would want some sort of authentication, be it very simple, like an API-based, like a very simple token-based authentication to a very sophisticated or 2.0 authentication. But you would want some kind of authentication. You would not want to keep your third-party web service or the endpoint open, basically. So there are certain authentications that you can use with FireBooks. The first one is the API-based authentication. So this is one of the basic authentications where you have a static kind of an API-based key that you add to your Webhook calls. And this key is used for authenticating your calls to the third-party web service. A lot of times you would like to hard-code this in Marketo. But since these are unlike the access token that are short-lived in the over 2.0 authentication, these are not dynamic. And at the same point, this is convenient, but they themselves can be vulnerable if compromised. And then there’s another authentication type that is the basic authentication. So unlike the API-based authentication where you had a single string, the basic authentication has a combination of a username and password. And you send these two parameters in the request header. And these are encoded in the base64. So this is a little bit more secure and a little bit more… It’s better than the API-based simple authentication. However, it still has its own vulnerabilities since this is not dynamic and remains static. Next up is the over 2.0 authentication. So this is the default authentication that Marketo’s REST APIs use. So people who would have used Marketo’s REST APIs, they would know that Marketo uses the over 2.0-based authentication. You have your client ID, client secret of an API user. You use that to generate an access token that is short-lived for 60 minutes. And using that access token, you authenticate your request to Marketo. So that is a gold standard, kind of like a pretty good authentication mechanism. So you can also have your third-party web services use the over 2.0 authentication. Earlier if you remember, when I said that webhooks are stateless entities, the response that comes in webhook call 1, you might have to do certain configuration so that you can reference that data in your webhook call 2. So what that means is you can have the first call you can make to get the access token. And then you would need to save that access token to a lead field or any other field basically, and use that access token as an input for authenticating your second access token. So this is a bit like, of course, it allows you to have your webhook calls very much secure. At the same time, when it comes to implementation, you would need a little bit of more setup campaigning-wise to use this. And then there’s custom headers. So you can add in certain headers that has the secret strings or tokens for verification. And of course, this approach offers flexibility, but requires proper management of the secret data as well. Yeah, so let’s talk about how you can use webhook in a market or smart campaign. So you can only use webhooks, call your webhooks from a trigger campaign’s flow. As of now, trigger batch campaigns do not support the webhook call. And then there’s a way, a workaround that we’ll be discussing towards the end through which you can also call, like make a webhook call from a batch campaign kind of thing. But yeah, so yeah, like I also already mentioned, you can use the request campaign flow step from a batch campaign flow to call a webhook from a batch campaign, a daisy chain if you will. But in our later slides, we also have showed this with a snapshot.

Could you move on to the next slide? Yeah.

I’ll let Josh talk about some of the use cases where you can use webhooks. Sure. So if you have a non-standard CRM integration, or if you have multiple CRMs, we know you can only connect natively one CRM, Salesforce or Dynamics. So if you have something like that, it’s a very good tool for webhooks when something changes in Marketo to reach out to the CRM. So you can create a webhook that goes through your service with all of the relevant lead data, any data that you want to sync from the lead record to that service. It can also pull whichever CRM or external service that you want, maybe a CDP. And then compare those records, merge, and so they can also not only update the CRM, but also pass back any updates that CRM has for that record. You can do this bi-directional that way, or you could have a webhook that simply pulls the CRM and brings back any updates, or doesn’t need to be CRM or whatever service, pulls it and pulls back any updates, or just a push one. So it just pushes updates out. So whatever requirement you have for the external system, you can build it that way. Next, we have event management. If you need to register people in a third party service, you can send out that they’ve registered through your Marketo form or through your Marketo program. Send out that that registration has happened. Or vice versa, if you need to check within a third party system, if that person attended an event, you can reach out and pull that event in. E-commerce. If you have an external e-commerce system, you need to pull in whatever product someone is interested in or has bought in the past. You can do that as a pull or if you need to push, maybe you need to push a… I think your sales would happen in the e-commerce system, but occasionally there’s things where someone has shown an interest or something like that, or initiated a refund or something where you could push it out to your e-commerce system. And then cloud storage. If you have data that you don’t want to keep in Marketo or you want replicated or anything like that in this cloud storage system, same thing. You could set up a webhook where you set up that payload where you have all the data that you need to store in your cloud storage and go ahead and push it out through a webhook through that efficiently. One question again is, as Darshan mentioned, that these APIs and webhooks are separate. Sometimes I get the question, well, if we get data back from the webhook, does that count as an API call? We only have so many API calls. No, none of it counts as an API call unless you use the actual API. I’ll continue. So some more use cases around marketing or lead generation. You can trigger marketing programs based on lead actions. So whatever you need to push out, I’ve seen this for PPC campaigns, things like that, where you need to, or promotions, where you need to figure something in another system to tell it, okay, someone took an action. You can go ahead and do that. Sales enablement, you can send sales alerts. We’ve used it for SMSs, things like that directly to our sales team to give them live updates about activities that are happening. Close with reporting. So oftentimes if you have a reporting system, especially if you have a live reporting system, getting that data back and getting it into that system as quickly as possible is very important. And then personalization. There are many ways to do this. We have print on demand, we have SMS, many different ways. If you have another system where you need to get the specific data from the lead record or the program member fields, you can set up a webhook and call it like that. Thanks, Josh, for covering the use cases. Now we have a bunch of pro tips and some of the workarounds and as well as some of the technical limitation of the webhooks that we will try to cover. So the first pro tip that I personally have encountered while my usage of webhooks, when I started with marketer is when you update a webhook, when you already have a webhook and when you are making updates to it, once it’s created, then those updates do not get reflected. So for example, you had a webhook A, then you made certain, like you used it in your campaign, you made call, you return some data. And then if you want to make an update or like you are just testing and then if you want to make an update, that update won’t get reflected. So marketer is still marketer, even after saving the updated webhook definition, marketer would still make a call with the previous webhook, like the definition and the configuration. So, you know, I have talked to PMs and the one reason that I got from them is that marketer caches the webhook definition. So it usually takes some time for webhooks definition for that cache to clear out. There are certain, like I have seen use cases where that cache didn’t get cleared even after like two or three days. Even if I call the updated webhook call, marketer is making the same, like with the stale webhook definition call. So usually what I recommend and what I do is like instead of making an update to the existing webhook, I clone it and update it and then use it in my campaign. That way it allows me to also do some version control because these webhooks, they can get pretty complex, complicated with certain payloads. And of course, if you are using some of the webhook calls where you are using JavaScript as a language, like to execute certain commands in the payload, then you can also do version controlling and allows you to roll back or refer to an earlier version of the webhook pretty easily. So if you want to update in webhook, I usually prefer cloning and then making an update instead of making an update to the existing webhook because that you can risk where marketer is calling the stale webhook configuration. Yeah, so this is something that we covered earlier, like we touched upon when we are discussing about calling webhook from the campaign. So natively market only supports calling webhooks from the trigger campaign. But if you want to make a call from the batch campaign, you can do so by having a request campaign flow step in your batch campaign and then having a requestable campaign. That is a campaign with a campaign is requested trigger in its smart list. And of course, you can have certain filters if you want in that campaign smart list and in that campaign’s flow, you can make a call to the webhook. So technically we are calling a webhook from a trigger campaign. It’s just that that campaign is being requested from a batch campaign. So it’s a daisy chain kind of mechanism that you see there. But natively, if you call a webhook from a batch campaign, you will get a 1000 response code back and that webhook call won’t be successful. I guess in this case, Darshan, the intention is that you overload the webhook. So it’s not something you’d want to do for big bulk of audiences. You want to understand your destination person, what it can handle before you take this approach. I see a question in the Q&A that says, how can we replace webhooks with self-service flow steps as webhooks have some limitations? This would be where you would do that because self-service flow steps send the requests in batches of up to 1000. And it’s asynchronous, so it doesn’t have a timeout limit. But this would be a specific area. If you’re already doing this and you have access to a dev team or tool where you can build self-service flow steps, I would push you in that direction. But it is possible if you are careful to do it this way. So error handling, as I mentioned, you want to make sure you’re getting 200s back. 200 is just an HTTP all good status. So what you can do is there is a filter once you start using the webhooks. There’s also a filter and a trigger. Here you can use the trigger webhook is called. And here you get the response is, which you get the response and if there’s an error, the error type. And here you can just filter out, see the errors you’re getting. If you’re getting an error, maybe you want to trigger an alert to you or you want to trigger something to run again. This is how you do it. This is how you trigger. You can run it as a trigger as it’s shown this way or as a filter that you run maybe daily or something like that. I also want to add one thing here. So, you know, in one of our earlier slides where we were, where I discussed the authentication methods, I briefly touched about the OAuth 2.0 authentication method where like you would want to make a configuration where you want to preserve the state, basically get the access token from the call one, webhook call one and use it in the second webhook call. So this is something that you can use like in a regular trigger. You can say like webhook is called, like the first webhook is called and you get a 200 OK response. And then in this particular campaign’s flow, you can, you know, make an outbound call to like your subsequent webhook call. And since this particular trigger will only fire when the first webhook is successfully called and you already have the access token written, like, like written from the system. And then you can use that access token and make the authenticated request to the same service using like the access token, basically. So, yeah, that’s how basically you can introduce or bring about the statefulness in the state, like using the statelessness nature of the webhooks.

So continue with the error handling, handling predictable errors, set up decisions and flow steps to handle the predictable errors, as I mentioned, and exceptions. You can use parameters to identify specific error messages if you want to take specific actions, depending on what kind of error you receive, maybe once an alert, but once a retry. You can go ahead and set them up that way. Automate error recovery. Sometimes you’re able to, depending on the external service you’re using and you’re integrating with, some errors can automatically be recovered from. So if it’s throttled or something because you’re sending too many requests, if you did it in a batch campaign. So it’s possible to just schedule retries, schedule a wait step or wait till later and schedule those again. And then, as I mentioned, set up alerts for unexpected errors, anything that you can’t retry or fix, then send alerts. So you as the admin or whoever is responsible for that gets the alert and knows, hey, something’s up. So you can go in there and figure it out and make it work. And then an investigation list. As part of the error handling mechanism, you want to include the people who are responsible, designated investigation lists. And that will be who’s responsible for specific actions, for specific items, so they can go in there and take care of those items. And clearly mapping out all of your webhooks and backend services helps to do that. So as Darshan mentioned, calling a webhook is only valid in trigger campaigns. Even though there is a workaround, I don’t advise it. I’ve seen some messy things. Some servers go down and then trying to figure out, OK, which records did work, which ones didn’t. It can be messy. In those cases, I would suggest self-service post steps or maybe some other solution where you run it in triggers. It’s one at a time execution. So webhooks are always called one at a time. And they have a 30 seconds limit. So if your server doesn’t respond in 30 seconds, if you can’t do the action that quickly, you’re going to get a timeout or you’re going to lose data. So you may it may be a case where you are expecting a response back. And even though you started the process on the server, if it doesn’t give a response back to 30 seconds, it can take the action. But Marketo never. Marketo reports it as an error, a timeout. But it actually happened on the other end. So then you have two systems that can be out of sync depending on what service you’ve set up. And oh, sorry, I skipped over one at a time execution means, you know, because you’re doing one record at a time, some some of you, I’m sure, have some massive databases in the millions. If you are running even 100000 records through something and it’s running one at a time that it can balloon up on a time that it’s taking to run that that can slow down your system. Definitely crash your back. And so just be aware of that and maybe other alternatives or be a little more strategic about how you employ webhooks, if that’s going to be the case. The Q&A. Great. Yeah, that was it for the main theory of the webhooks. I put a question in just the normal chat that if anyone has use cases that they’re using webhooks, I think I’d be interested to hear how the community is doing. But looking at the Q&A, there was one question which Josh you already touched on about self-service flow steps compared to webhooks. I don’t know if you have any more points you want to cover on that. I would say. Helping decide when to use which is the right approach. In most cases, webhooks, what they’re going to give you is simplicity. You can connect to something like Zapier to Microsoft Power Automate, to make.com or I think Workato. So it can be quickly set up. You don’t need a back end server really. It can be really quickly set up. Whereas self-service flow steps, they’re a little more involved to set up, but they’re a little more durable. They run in bulk. They are a little more reliable. As far as you know, you don’t have any timeouts if it’s designed correctly. So there I have an article in the community which goes through all of the limitations and where self-service flow steps would be your best option. But in general, where I would choose webhooks is simplicity. If I have something where I know I can just make one call and be done, my server is not going to take a long time to respond. I don’t need a response back. These are where I would use webhooks. And if you have access to a developer, you can use the template that 51ºÚÁϲ»´òìÈ has put out for 51ºÚÁϲ»´òìÈ IO. You can build it on any cloud service. I recommend using a serverless architecture. So like Microsoft Azure Functions, 51ºÚÁϲ»´òìÈ IO, something like that. The one kind of cloudless platform that I know has a specific self-service flow step option is Workato. There may be others, but that’s the only one that I’m aware of. I think that maybe goes on to the next question, which was from April. About what would be a use case where you wouldn’t be able to use a webhook, but would it be preferred to use a middleware like Zapier or Workato? I think that touches on maybe Darshan’s first question about webhook vs API. Just to clarify, Zapier or Workato could be used with a webhook. That could be the service that you’re calling. But to kind of put it in the self-service, when you couldn’t use a webhook, if the response is going to take more than 30 seconds, absolutely not. So if you need to call open AI or an AI service and get a response back, it’s probably going to take more than 30 seconds. You’re not going to get in time. Or if you need to do things in bulk where you have hundreds of thousands of records that need to be processed. Those are the two that I see most often are just too much for webhooks. Those are great points. And to add on to that, certain times, I feel that the middleware, Zapier, Workato, they kind of help simplify integrating multiple platforms. So if you want to compare that with a webhook, so you would not have the ability to make an API call to a certain service, to a certain platform right there and then from Workato. For example, that particular platform doesn’t have an accessible, publicly accessible API endpoint for you to call from the webhook from Workato. In that case, but however, if they have a work at all, as an integration with that particular service or platform, in that case, you would not be able to use a webhook and you would want to go with the middleware like Zapier or Workato. Yeah, kind of adding on to that. Anything like authentication wise. You gave an example of how to use OAuth, but a lot of cases you wouldn’t want to put your keys in there. It’s a little cumbersome to build. But I would probably put that into a third party and you can do that with a webhook still, but put it on the service. Or if you need to tunnel into something like a VPN or something into a service where you can’t authenticate directly through a hook. Exactly. I think it was, I remember a lot of people talking about it a while ago and I was always jealous that they were using webhooks for the company that used Slack as well. So you’d get an alert anytime there was a certain failure or maybe there was a lead that came in with data that didn’t fit expected values for maybe country code or something. I found a way just doing some googling because we have teams for everything, Microsoft Teams. So I created a webhook that will send me a Teams alert to a channel every time that there is a failure on a different webhook that I have. So I have webhooks triggering off webhook values for certain things. So it seems to work quite well. I had it previously set to an alert and then it was just my inbox that got flooded or it was all on me to maintain. So that was a way that I made it share the responsibility across the team that way. Really? Yeah. I think other ways that I used it in the past were also replicating a similar idea to interesting moments, but storing them externally. So we’re using a webhook to post that to like a streaming endpoint where we can send off the data after we generate it based on like an example given earlier. If there was an event attendance or some form field content download, also making that then available to CRM. So there’s a bit more of that marketing history available. And something I’ve been looking at lately is the idea of not having everything to marketer. And in cases where we have multiple systems of record, calling a particular value, like account manager at that time, that may be in commerce or a massive data tool or in CRM or those types of things and calling real time depending on what value we need rather than maintaining both in the marketer. Yeah.

Yeah. Sorry, Josh. I think that comes to the end of the questions that we had in the Q&A. I do not see any.

I got quite to that. Yeah. So that is great. Here we go. Two questions coming in from Mike. So let’s just have a quick look. The first one he says is when you use a webhook to enrich a new person record, such as pulling info from Zoom info, if people are added to the database in bulk from an imported list, so say over a thousand people, for example, what are the best ways to throttle the call so that you don’t overload the Zoom info end? That’s a good question.

Darshan, any ideas? I would definitely jump to a self service flow step for that. Yeah, that’s what I was thinking. Yeah, definitely jump to self service flow steps where you can, like where you get more control than webhook because if you have a triggered campaign that is just calling, like making a call to a webhook that then makes the call to a Zoom info, you would definitely, yeah, flop it. Yeah, yeah, flood your system basically with a lot of webhooks, like webhook calls. So, yeah, I honestly would move to self service flow steps if you are seeing, you know, a lot of similar incidents where you are importing records in bulk and then your system is getting slowed down, bogged down, you would want to move to the self service flow steps instead of webhook calls. I would quote that route. Yeah, you know, instead of optimizing that particular triggered campaign for 1000 or 2000 or even 5000 record imports, I would probably go to the self service flow steps where my system would be at a better point and be able to handle larger list imports. That’s the point where I would go. I guess you could do like, first of all, you could do the error handling where you kind of add people to a wait step where they get retried, things like that. You could do the random sample and just whittle it down until it was a smaller number and then process them all. It would be complex, I think. Yeah, I was thinking random sample too and it would be good for maybe one time when you have 1000 records and you break them to 200, but then if the next time is 10,000, then you have groups of 3000. That’s not a super scalable. Did you have a second question, Mike? I think. If there’s no more questions, we’re also almost at time so we can. Great. So we’re almost at time, so I will just quickly move this. As I mentioned earlier in the intro, the Adorees Code Option Retention team have a few, would like your feedback and input on things. So if you want to have time to take a quick survey, please scan the QR code on the left and fill that in. Else, if you want to have a more in-depth chat, give some good feedback, please scan the QR code on the right. And apart from that, we are done for the day. Lots of nice compliments coming in. So thanks to Josh and Arshad for sharing your knowledge. Thanks everyone for joining. Thank you. Bye. Thank you. Bye everyone. Bye.