I only became aware of the concept of Webhooks in 2014. Their concept has been around a few years longer than that, and you'll find very few SaaS products that don't leverage them in some way or other. And they're popular for good reasons: they're an incredibly simple concept, can be applied to literally any system that generates events that others may wish to consume, and producing or consuming those events is extremely simple too - they're (usually) just HTTP POSTs with (usually) a JSON payload.

The payload of a webhook message, however, can vary from use case to use case. Products may implement standard integrations for popular products (such as Slack) where the webhook will send the message in a format appropriate to the receiving system. Other times, the receiving system (again, such as Slack) might have an integration specific to a given webhook source, which knows how to parse the message that it will produce and turn it into something that makes sense to a plugin API. And then other times, you might need to do something yourself...

So, back to the problem in hand: how to get event messages out of MailJet, into a system where we can see those events as they occur.

My Dad and I tend to use Google Chat (formerly Google Hangouts) for real-time messaging. Last year, Chat started supporting the concept of a "Room" - basically like a channel in Slack or other chat systems. But also, like Slack, these rooms support the creation of incoming webhook URLs to allow messages to be posted into a chat from an external system. What a stroke of luck!

So, just for a laugh, I decided to point the MailJet events at a Google Chat webhook to see what happened. Unsurprisingly, nothing happened. The message that came from MailJet did not match the format expected by Google Chat's WebHook. Figuring out how to correctly form a message to be consumed by a Google Chat Webhook was easy enough just by referring to the documentation. The message format that MailJet emits, however, is a bit more complex. MailJet have their own documentation, of course but sometimes it's easier to just get a look at the actual payload for one of these messages. And this is how I came across Request Bin which you can use to generate a URL to point any Webhook source at, and then inspect the messages that come in. Obviously use this with caution - the free tier is not private and therefore any events you fire into it could be looked at by anyone. So I generated a test event from MailJet, and this is what appeared in Request Bin:

[
    {
        "event": "sent",
        "time": 1565514085,
        "MessageID": 0,
        "email": "",
        "mj_campaign_id": 0,
        "mj_contact_id": 0,
        "customcampaign": "",
        "mj_message_id": "",
        "smtp_reply": "",
        "CustomID": "",
        "Payload": ""
    }
]

Pretty neat. Now we know what we're dealing with on both sides of the fence, we can do something about getting events out of MailJet and into Google Chat! This is where Azure Functions come in, and that's covered in the next post in this series.