Testowanie e-maili bez spamowania kogokolwiek

Hey, welcome to Bird. In our previous videos, we've already gone ahead and set up email for my custom bird shop. Um, but we've only sent out simple sending. Um, we tested this and it worked and we did the entire happy path. Unfortunately, not every email that we will be sending will be following the happy path. Um so today I'm just going to quickly show you how to make use of our mail sandboxes so that you can actually integrate your application also for the unhappy paths that might occur at a certain stage. So I've opened up our documentation here um where I've got extensive information but in essence what the mail sandboxes allow us to do is actually set up um web hooks to start receiving the events for the non-happy paths. So for different statuses of emails, we've set up specific magic email addresses. So if you send an email to delivered at messagebird.dev, it will follow the happy path, meaning email accepted, email processed, email delivered. In some events, it might also be the case that we send an email to an email address that doesn't necessarily exist. In those cases, we will get a bounce. So for that, you can use both bounce and hard bounce at and we'll actually follow the same process except we will return a bounce state. So, we've got email accepted, email processed, and then email bounced with a bounce type, for example, a hard bounce.

Same for soft bounces. We've got this for deferred and delayed. We've got this for complaint and spam reports. We've got this for suppressed. And we've got this for rejected. So, why is this of interest of you? Well, this will actually allow you to test out all of these different states with the web hooks to actually start integrating this into your own application. So, what I've done for now is I've opened up a new terminal and I've just got an example um send where I'm going to be sending specifically to deliver. So, I'm using the Bird CLI for this to quickly send and we can see that the accepted state has been returned. Now, I'm going to do the same thing of sending an email to a bounce and then I'm going to do the same thing to a complaint.

So you don't have to worry if you've got a domain set up already because we're using our messagebird.dev domain for this. Um this won't actually impact any of the statuses of your specific sending domains. Now I've also opened up a web hook. So I've integrated web hooks to this so that we can actually see how the system is processing the responses for each of these. And here we can see the recent ones that actually came in.

So here we've got the one to delivered. We actually have the type email delivered. So everything is happening as expected. So here we can see the other one. We can see the email was accepted. It was processed. Now here we've got one for the bounce. So this was the process event. This was the accepted event. And here we can actually see the specific bounce return.

So we've got a few additional information points here. So we can see the bounce class, the bounce code, um the bounce description. So why was a specific user bounced? And we can then start using this information within our own application to make any updates as desired. For example, for bounce, we might want to clean up the email address to make sure that we don't send to them in a future campaign or future uh broadcast. Same thing goes for uh the other flows.

So, for this one specifically, we've got the complaint and the complaint came back as abuse. So, we want to make sure that we stop sending there because this specific user um actually doesn't abuse us or doesn't like our emails. Um, on top of that, we can start using these metrics to build out custom reports, custom use cases, and custom advanced to really enable us to better tune our emailing to be as best as we can.

Now, all of these events can also be found back in our email logs. So, if we go into our email metrics and email events, we can see that the emails were sent in. And then we can also see the specific cases for um those events. And then under the details, we can see the follow event of that specific use case.

I would highly recommend to make use of this. And then the web hooks were set up under web hooks. So here you can set them up. The events that we've used is uh all of the different email events allowing us to start sending those events back to our application to start working on those. We have a different video on web hooks al together. So if you want to learn more, have be sure to have a look. And don't forget to look at our multi-part series of integrating all of our channels into your application.

Happy sending.