Are Webhooks Dead Yet?

[0:00] Alex: Okay, got 15 minutes to figure out if webhooks are dead yet. Yesterday, actually that was on Tuesday, Vanessa kicked off the keynote and kind of middle of the keynote, she mentions how like webhooks has been the problem for every Shopify developer. And it's the big thing that I've been kind of a recurring theme for the last decade. I want to quickly check whether or not that's correct. Can I get like a show and who struggled with Shopify Webhooks or Webhooks from any other. Okay, it looks like she was pretty close. And who wishes Webhooks were dead? Can I get a show in on that? I'm about to disappoint a couple of you. So quickly myself, I'm Alex Atixon for the French here.

[0:50] I'm actually French Canadian. I'm the CEO and also the co-founder of Hookdeck. There's a couple people here in the team. got Maria, Sussito, other folks. We've got a room. The stamp is in the room for everyone looking for it. Otherwise, I'm not going to get any of you in there, so I have to do something about it. For those that don't know us, we're trying to solve pretty much every problem around the sun when it comes to webhooks. But most specifically, and the reason I'm here is for your event gateway product. So the event gateway is a new cloud infrastructure permitive to receive events and webhooks into your infrastructure. So it's part of ability, queuing, event management, event routing, filtering, transformation, deduplication, and so on. And people often think we just received Shopify Webhooks. It's actually a small but meaningful amount. We get Webhooks from 7,000, 7,500 different

[1:45] Webhook providers now, and some of the usual suspects are gonna be Striped, Twilio, TikTok, WhatsApp, Clavio, whatever you name it. Some backstory. And part of the reason why this place matters to me is I come from the commerce ecosystem. I was working for a big merchant based in Montreal called Rachel. That's like a decade ago. Did the whole who commerce to Shopify migration. Definitely lost couple of air in the process. And then back then we also built a bunch of tech, custom tech, so we had our own homemade user account subscription management, edless storefront, fulfillment, warehousing. And as part of that, Webhook just became a total mess. So we had Webhooks from Shopify, Intercom, Stripes, ShipStation as part of making older services work.

[2:36] Thank you, Joda, for the mic check. And about that decade ago is where I discovered the Webhook iceberg. So back then I was mostly full stack developer, actually started as a product designer originally. And so I didn't know shit about dead alert cues and in the potency and all those nice stuff. So when you look at webhooks, you're like, oh great, it should be post request, what can be hard about that? And then you start getting more and more and more and shit break and it doesn't work. And then you wonder where the webhook went and then you discover the whole rest of the iceberg. So I'm here today because apparently webhooks are no longer cool. And now we're talking about next-gen events. And I'm kind of joking about it,

[3:26] but I think that's the best thing that Shopify could have done. It feels like we've been talking about this for such a long time with very minimal changes in the process. And now it's changing everything all at once. And so I think we have to think about it. And if something is going to kill webhooks, It's going to be next-gen events. So the first thing I want to highlight and why I think this topic matters is because a lot of you actually have stayed away from WebEx. You've looked at the iceberg and you're like, I don't want anything to do with this. I'm just going to run some cron jobs and pull the API instead. So I want to highlight this post on X that Pakkar from Foxell that you guys probably know. It was like a freaking Bible, so I can put the whole quote on there, but I think the part that matters is basically the disk changes everything.

[4:17] And the highlight there is that a lot of you are about to like deal with that iceberg. And so I wanna go through like some of the game changers, the things that like next-gen event is truly changing, but also some of the things that maybe are still going to be top of mind going forward. Number one, for those that went to the session about next-gen events from RG, probably know all of this, I'll try to go quickly, but for those of you that have been living under a rock, some of the key changes. First, GraphQL alignment. So the current webhook schemas are based on the old REST API and a lot of new fields have been adding to the API. They are not represented in the webhook schemas. And so with this new GraphQL API, now you get actually consensus between the webhook data that you get and the queries that you define for the GraphQL data that you wanna get in response to the webhooks, but also the original webhook data. Sorry, no longer the original webhook data

[5:09] with just like all the fields that you didn't necessarily care about or didn't align with the rest of the fields that you got from the GraphQL API. And then the second thing is that you actually get to know what changed. That's like a key thing people have been bringing over. Like is it in this example, the variant price that changed? And you can anchor your application to react to specific changes instead of trying to have to figure that out yourself. The next thing I wanna highlight, and this comes from the live stream that Taylor was on, but already forgot everything about it apparently. This quote from Sandish saying, "Aphrover AWS bill is consuming webhooks, queuing them and making sure we can manage them." This just blew my mind. That's insane that it's such a big part of the infrastructure and the infrastructure burden. And they surely listened because now with the new next-gen events, you have triggers and

[6:02] filters. Triggers and filters allow you to be much more specific about the data that you want to get. with some configuration complexity, but at the end of the day it gives you so much more granularity around what specifically you want to receive, and in many cases you can receive up to 90, 95% less webhooks, and that's mainly driven by the product updated webhooks and the inventory changes that have been extremely noisy. Now obviously that can be a silver bullet, especially in the case thinking about you, where you do actually want to get all the data, right? So that only works to the extent where you don't want the data. But ultimately, now the choice is yours, and it's your control of what you actually want to get. And that makes a very meaningful change. That being said, we can't ignore the rest of the iceberg. Because what we talked about mainly touches on the actual H&B post request, which request that you get, what data contains. But a lot of the challenges around managing those events,

[6:54] like coming to your infrastructure, are still true today. 15 minutes is not enough to start breaking down what the dependency is and how to implement solutions to it and all that. But I want to focus on key three things. That when I'm having a conversation with some of our customers and users in this room, but also some of you that are just depending on webhooks, the things that keep coming over and over again. One is our visibility. Right now, it's still very difficult to know what actually the webhooks are that have been sent to you. In the dev dashboard, you do get a list, but it's basically just like a static list with filters on status. So you can't find specific product ideas for specific stores and knowing the statistics around which topic or during volume, which store that might not even be a paid customer for you or sending a lot of web book to your server, that sort of stuff. Second, you can't actually find specific issues.

[7:47] So if customer support comes through and it's like, where the hell is this order in the fulfillment system? And you want to trace what actually happened with the processing that webhook. Right now, there's really no solution to this. And then second is replayability. Inevitably, U or Codex or Claude is gonna, sorry, fuck things up, and you might do a bad deploy, don't process the events the right way, need to go back in history, replay it. You might have server outage, database connection issues, all that sort of stuff that all ultimately result in you having ways of being able to keep the web of payloads and be able to reprocess them. Second is this noisy shock problem or for the distributed system nerds, the noisy neighbor problem. So when you have specific stores, you don't actually control what they do with their stores and the events and webhooks that it generates.

[8:37] So routinely we see, for instance, merchants that will use the ERP and will do like full catalog sync every single morning and will generate a million events all at once. And that tends to be disruption for all the other stores that you process. Solutions to this are pretty complex and I'm gonna talk a bit more about that later. But ultimately, you have this trade-off of how far do you go in the technical and architectural complexity to solve this problem versus how much do you accept that if one big merchant does a bulk update of all their customers or all their prices, that it jams up your capacity to process events from other shops. Last but not least, we're not just talking about Shopify Webhooks. We're never just talking about Shopify Webhooks. Everyone gets Webhooks from all over the place. There is thousands of vendors. And especially in the Shopify community, we see people integrating with other e-commerce store,

[9:29] customer support system, inventory fulfillment, also shipping providers like UPS and all that sort of stuff. And so usually when you're thinking about those problems, Shopify is maybe the biggest event source, but it's really the only event source. And so solutions tend to be, you tend to be looking for solutions that are agnostic across vendors. Time to answer the big question. Our webhooks is dead. And obviously this is controversial. Some people might not like this. Some people might like this. I think in the past we've seen that Shopify is pretty good, maybe too good at deprecating stuff. And so if I had to make a bet on the future of WebEx as a primitive in the Shopify ecosystem, I think the writing is on the wall. That's my personal bet. I have no insider information on that. But it doesn't mean that the iceberg is going anywhere

[10:21] and there's still gonna be WebEx and the other vendors and all that sort of stuff. So are our webhooks dead yet? They're definitely getting a rebrand, that's for sure. And I think when it comes to the primitive in Shopify itself, it's very clear that you should be applying to move to Word next-gen events. There's gonna be huge benefits from doing that. And I personally feel that it's something that should be fairly high on the list of people that do rely heavily on those webhooks and events right now. And I think in the short term, there's a lot of benefit gain, I think in the long term, you'll probably have to. So what do we do? We start testing. It was in the workshop during.dev. It was said that the expected release is for 2026.10, the version API, so that we're looking at October. Now we'll see which one of you guys

[11:11] are comfortable going live with this before Black Friday. But if you start testing now, you might actually. And if anything, it might save your butt when you get there. So part two is give feedback. ArchDEEP, the PM, there has been very good at listening to people. A lot of folks here I know have been giving them feedback and has definitely been listening, has been quoting some of you the same way I am. And then lastly, and that's the part where I sell my wares a little bit, implement resilient observable infrastructure that might involve us, that might involve other tooling and whatever your cloud provider offers and what you're currently building on. But on that note, (singing) grant announcement, I wanna announce something we've been mailing for last year. So we've been talking to a lot of you and that noisy shop problem is the one of the thing

[12:03] that's been coming up over and over again. And we've rebuilt our infrastructure to be able to offer a solution to this called Deliver Groups. The idea of Deliver Groups is that you can configure specific throttling rate on a per store basis. And so what we do is from whatever the xshopify shop domain value is, we can dynamically create thousands of Qs and respect specific delivery rate for specific tenants. And so if one tenant generates-- sorry, using tenant, one shop generates a lot of volume, the delay is going to be strictly limited to that specific store. And we do that while still respecting your server capacity. and UGDAC is responsible for fair delivery across all the stores that have back pressure. We also tie that in with issue notification and Slack or incident IO or pager duty or whatever you use to alert you

[12:55] whenever there's stores causing this. And we give you all the metrics around which store, what the delay is, how many events is there, how long is it gonna take for it to empty and give you controls to change the throughput, cancel those events, re-queue them later, that sort of stuff. We do have a little demo, nothing like Tube Big, but if you want to play around with it in our glass box, and to give everyone another incentive, I remind you there's the stamp in there. So someone's going to be manning the box to stamp your sheets.

[13:29] So I guess that's it. Thank you. [APPLAUSE]

[13:40] 15 minutes to short for Q&A, but you know where to find me. So if you want to talk about it, I'll be around and probably at some point in the glass blocks too. So cheers guys.

[14:10] Okay, apparently I did a good enough job and now I'm getting Q and A, so. Does anyone have any questions for me?

[14:22] Audience: Hi, thank you so much. That was amazing, amazing talk. Thank you for sponsoring the event. Appreciate it, thank you. You mentioned that Shopify tends to deprecate stuff, which, okay, sounds good. And so in terms of webhooks specifically, so we have a lot of webhooks that are running in production. And that's been the case for years now, across our services. And so the events API seems very interesting, it's cool, it's the way forward, you're not getting inundated with information you don't need, you're getting your exact payload and so on. And so from a realistic capacity perspective, 'Cause there's such a core primitive, like webhooks I don't think are gonna be going away realistically. So would you say like generally it would be wise

[15:15] to slot in a webhooks to events, API migration, say this year or maybe first half of next year, what sort of timeline you think would be optimal in terms of like not just moving, but it's probably here to stay. So, webhooks are probably here to stay, no?

[15:35] Alex: We'll see. I'll touch on the last thing quickly. They're, and they've been public about this. They're billing this as a separate system. They got brand new systems starting pretty much from scratch. Ask yourself, all along would you maintain two separate systems sending billions of events a day? All right? All things a lot of incentive to do that. So that's just me projecting, speculating. Hopefully nobody in the room's mad at me for that. And then the other part of it is that the amount of attention and craft that's been going into next-gen events gives me confidence that this is going to extend to the quality of the actual operational service. And I know they've been concerned about webhook latency issues. Like we have a service called IGDEC Radar

[16:26] that monitors their real-time latency, Shopify webhooks and send alerts. And now I know that their engineering teams is looking at it and a little bit bothered by it too, but the point is, I know they're aware of this, they're working on this, they're keeping attention to this, and they've shown the attention to detail and care that in my opinion, if you are heavily relying on it, there's very little reasons to wait until the point where they say it's generally available. That's my take, maybe I'm taking the word for it a little too much, some would say. But from what I've seen, like Sandesh, for instance, like reducing AWS infrastructure costs by 50%, are you really just gonna sit on that for a year? You know what I mean? And so that's my personal opinion, but everyone makes their own trade-off and calculus on risk tolerance and so on. Thank you.

[17:20] Speaker 3: Hi, I have a question on the new feature. You were saying that you can rate limit specific shops, tenants to make sure the infrastructure doesn't buckle and the other ones are not delayed. How do you make sure that a store that every day sinks their whole inventory still gets all of the updates to you, right? If I set the rate limit too low, I might not get all of the events that they did in the morning until the next 24 hour cycle. Do you have any indicator on that on how low I should not set it so I get still everything?

[17:51] Alex: Yeah, that's interesting. Like being smart around the delivery rate and so on. just to clarify, those rates are for the data that we send to your server. So a deck will accept whatever Shopify sends. We're never gonna send Shopify, like, oh, this was too much for this shop, right? And so you get to set your limit. Now we don't have anything smart in the sense, like, oh, for this specific shop, you send it to this, but we do send the alerts when you're queuing to back pressure and so on, and then you can make a judgment call on it. I do think being smart about it, at some point, might be good. The problem I think with a lot of systems like this when they try to be too smart, they don't really do what you want and then it takes you by surprise and then I don't wanna take you by surprise at three in 3 a.m. 'cause like our system thought it'd be good if like the rate limit was higher or something like that. So I think it's a tricky line to walk,

[18:41] but I do think there's probably ways that we can help with this, yeah.

[18:48] One more? All right, Tim. Tim, you're a lucky guy, you get the last one.

[18:58] Speaker 4: So with the current webhook system, especially with stuff like products being super noisy, if you're piping that through Hookdeck, does Hookdeck have any type of filtering? So you can do filtering there on what gets sent to your store, and also do you have any kind of data transformation ability?

[19:17] Alex: You're asking me about webhooks? Dude, they're dead. Why are we talking about this? No, no, yes, we do. So we support filtering, deduplication. Deduplication is basically the equivalent of triggers in the sense that you can subscribe to only specific changes in payload, and we're taking the job of figuring that out for you, basically. We do support full-blown JavaScript transformation that wrote in as posposing function on every single event that you get. You can do content type transformation, all sorts of different changes to the payload, like trim them down, and all that sort of stuff. And the other thing is everything we do is not specifically for Shopify. What we do works with every single event that you get from any single vendor. And that's why it's called delivery groups and not shop throughput management or something. It's trying to be agnostic. But yes, we do.

[20:07] Audience: Awesome.

[20:11] Thank you. Yep. [APPLAUSE]