Aprende / Conceptos básicos de la plataforma / Webhooks bien hechos: eventos de entrega fiables
Webhooks bien hechos: eventos de entrega fiables
2:47 min
Tu envío devuelve un 202, y eso es todo lo que la API puede decirte. Entregado, rebotado, abierto, reportado como spam: todo eso ocurre después. Este video lo conecta de vuelta a tu propia app: crear un endpoint de webhook en Bird, elegir los tipos de evento, verificar la firma con una sola llamada al SDK y ver un evento real llegar a un handler local con tu propio ID de pedido adjunto.
Qué cubrimos
- Suscribirse a eventos de entrega y entrada
- Verificar la firma de un webhook
- Reintentos, y qué pasa cuando tu endpoint está caído
Transcript
Auto-generated from the video.
Hey and welcome to another video. Today we're going to be talking about webhooks. Webhooks will allow you to basically get more information into your application when something happens on the Bird side. So when you send an SMS or an email for example, you get a 202 message accepted. Um but that's only the first state that your message can go through. It will be processing, it will be delivered, it might fail. For emails you might get bounce rates etc. etc.
Now instead of you having to ask for that information every single time, you can use webhooks to actually push that information into your application so that you can process that on your own side. So I've opened up our documentation um and went into webhooks and events and you can immediately see here that there is a few steps that we need to go through. First one is actually creating the endpoint which is actually where we're going to be sending the data to.
And then we're going to be submitting that into our uh workspace. So when we navigate into our application, we can find webhooks in the bottom left corner and you can see I've already created up a webhook myself. When you create a webhook there's a few events that you need. You need the endpoint URL which is basically where Bird will point the updates to. You can give it a name. And then you can subscribe it to individual events. So these are the individual events that we will trigger on um to send into your webhook. So if you have a specific flow for your domain suppressions and your domain events, you would only be passing the failed and verified domain so that that is the only update it will receive from that specific endpoint. Now in the event that we add additional events to a specific uh webhook um event, that won't be immediately added to any pre-registered webhooks. So that's something to keep in mind is that we'll never update any settings on a webhook that's already created.
Now there's several events that we can go through. You've got the email events, mailbox events, SMS events, voice call events, WhatsApp events. And then once your webhook is created, you'll receive a specific key, which will only show once, which you're going to need into your actual implementation.
Now, for my specific use case, I've already set up a quick webhook example. Um these will go into just a simple webhook site for now, but here we can see all of the events that have been triggered on um my current existing webhook. So, in this case, we have an email uh first state being accepted. Then the moment it moved into process, it was received. And then we have the actual state as well.
And upon each of these statuses, I can then proceed to create automations on my site to help me improve the implementation of my website and actual customer experience. That's webhooks in just 2 minutes. Happy sending.