New Feature: Custom Webhook Payloads August 2022 · ian

Intro

One of the most important pieces of a webhook integration is the payload that gets sent to your webhook subscribers. This payload is a contract, it's the JSON that contains all of the data of the respective event that was triggered. Here at HostedHooks we give our users the ability to dynamically update a portion of the payload (the data object), while maintaing some required standards. We implemented a standard to make sure integrations were as consistent as possible. We won't dive into the specifics of the payload in this post, but if you are interested, we recently covered this in a previous post, you can check it out here.

The Webhook Payload

This is an example of the JSON payload structure that webhook recipeints will receive. The only part of this that is customizable is the data object ("data": ...), which can be problematic for any webhook recipients that are unable to ingest JSON structured like ours.

{
  "data": {
    "foo": "bar"
  }, 
  "version" : "1.0",
  "event_type": "user.created",
  "created" : "2022-06-01T17:48:14.981-04:00"
}

In this post we are going to be discussing a new feature that helps solve that problem.

Payload Override

Starting today, users finding themselves constrained by the above payload standard will be able to override the payload and build something completely custom. This will be handled with a new API parameter that can be passed in with Message POST call to override the payload. The parameter is called override_payload and takes a boolean value (true or false). If you want to go ahead and override the payload, add override_payload: true into the message POST call and HostedHooks will exclusively send the data object as the full payload. This allows you to add whatever JSON structure you want within the data object and it will get sent straight through to the webhook subscriber.

This is what you send:

{
  "data": {
    "foo": "bar"
  }, 
  "version" : "1.0",
  "event_type": "user.created",
  "event_id": "12323124151",
  "override_payload": true
}

This is what your subscribers will receive:

{
  "foo": "bar" 
}

With this you can modify the payload however you want.

On the other hand, this is what your subscribers would receive if override_payload was set to false:

{
  "data": {
    "foo": "bar"
  }, 
  "version" : "1.0",
  "type": "user.created",
  "created": "2022-08-26T09:15:09.492-04:00"    
}

While you can see that the override flag makes your webhooks much more dynamic, there is value in standardization and we'd recommend that you still maintain some structure with your custom payloads.

No Code Webhooks

A great use of this feature is for integrating with applications that offer inbound webhooks. An example of this is Slack. When you want to integrate with Slack you can setup an inbound webhook endpoint on Slack and send webhook messages which in turn get processed and turned into individual slack messages. The problem was that the HostedHooks standard payload did not conform to Slack's webhook endpoint payload structure. But now, using the override payload feature you can build your payload in a way that conforms to Slack's needs and send webhooks directly from HostedHooks to Slack.

If this interests you, we will be writing up another post where we walk through integrating HostedHooks webhooks with Slack to trigger inbound messages.

Conclusion

For more details and reference you can checkout our API Messages Documentation

We're working hard to make HostedHooks the most versatile Webhooks as a Service platform and hope this feature unlocks a ton of potential for no-code and low-code webhook applications. We are excited to see what our users will build with this fucntionality. As always, let us know if you have any feedback, need any help or have any questions.