How to use Zapier to create automation workflows triggered by Bambuser content

In this guide we will look at how to react to incoming Bambuser broadcasts by listening to webhook events. We will use the cloud service Zapier (opens new window) to define an action to perform. Low-volume use of Zapier's core feature set is free.

Create a Zap

Next, press the Make a Zap button, which starts a pretty extensive but very helpful wizard.

Choose a trigger App is the first step. Choose Webhooks by Zapier, then select Catch Hook. Zapier now gives us a public https url where Bambuser can post broadcast updates.

Next, skip past the Edit Options / Pick off a Child key (you can always change your mind and go back via the menu on the righthand side).

Send a sample broadcast to Zapier

Zapier asks us to send some sample data to work with. Let's register this url as a listener on Bambuser dashboard's Developer Page (opens new window).

Next, use Bambuser's mobile app in the App Store (opens new window) or Google Play (opens new window) or the "go live" button in Bambuser Dashboard or any other broadcasting approach you prefer.

Titles are nice

Preferably set a title in your broadcasting tool of choice, as this can be a useful way to provide more context: the broadcast title can be reused as the blog post title and you can even take different actions based on the contents of it, more on that later.

A few seconds after you've started the broadcast, click the OK I did this button in Zapier and it should discover the webhook message you emitted. If you emitted more than one you get to pick one.

This lets Zapier discover the structure of the webhook message which will help us a lot when creating the template for the blog posts or whatever we want to achieve.

On the next page, Zapier concludes that Your Zap currently lacks an Action step. Add one now! Let's add the main action in just a moment, but first, let polish up our data a bit!

Filters: React only to new broadcasts, ignoring updates

The broadcast webhook will fire multiple times for a typical broadcast. Most of the time you get an add event, followed by several update events each time something has changed significantly, whether an edit to the broadcast title or a significant geolocation change. Another common update is when a broadcast goes from being live to an archived replayable mode: the type field indicates this state.

For simple scenarios where we just want to react once per broadcast, we need to ignore all update events, otherwise our target system will be spammed with duplicates!

In the right column, press the plus button below the trigger box. Then select action: Action, operation: matches exactly and value: add as the screenshot illustrates.

This is where it helpful to have that sample data illustrating Bambuser's webhook message structure available.

Selecting an appropriate sample event

In the screenshot we see that our sample event's Action actually was update - that's one of the ones we want to get rid of! It does have the same structure as the add event and would be ok to work with through the rest of the wizard in that regard, but since we just told Zapier that it should be filtered, it won't reach the following steps. If this happens to you, edit the trigger via the lefthand-side menu and choose another test event - emit another one if necessary

Hereby, whenever action is update, the event will be silently dropped and not reaching consumers positioned after the filter.

Formatters: Preparing the player embed

In most one-blog-post-per-broadcast scenarios, showing an embedded player is desirable - let's use the basic iframe embed approach. When constructing the player url, you must urlencode the resourceUri, since it is essentially an url transported within an url.

Fortunately, Zapier has a test formatter action, which is capable of url encoding. Add Formatter as the third step, directly after our filter. Choose the URL Encode Transform and select resourceUri as input.

When we run the related test, we see that https:// is replaced by https%3A//, & is replaced by %26, = is replaced by %3D etc. This is exactly what we want. In a later step we will be able to construct the full embed code.

The original resourceUri was not replaced, instead a parallel key was added. This means we have access to both variants from now on. On the lefthand side you can give your actions a more descriptive name so it is easier to find.

Formatters: Specify a default title

Let's add another instance of the Formatter, but this time target the title field. Sometimes the broadcast title field is empty: some RTMP ingest tools and the WebRTC broadcaster does not even expose a title field. And sometimes the user leaves the field blank even when a field is available.

Use Transform: Default Value, select Payload Title and finally, enter New broadcast (or anything you prefer) as the fallback value.

Bambuser → Zapier → Wordpress

Creating one blog post per incoming broadcast could be quite useful - let's examine how Zapier can help us with that. Zapier has native support for a lot of other blogging services too and the steps to integrate with those should be similar.

Create a blog post template

Let's add the WordPress action as step 5 in our Zap. As sub-action, select Create Post. Then connect your blog by providing the base url, username and password.

Now it is time to create a template that all our broadcast posts will use:

As title, don't pick the title from our Catch Hook sample, instead use our Filter / default title action's Payload Title, which we can see got the alternative value, New broadcast (assuming your sample broadcast didn't have a title either).

In the Content field, add the basic iframe embed code, something along the lines of:

<iframe
  src="https://cdn.bambuser.net/player/?resourceUri=URLENCODED_RESOURCE_URI_GOES_HERE"
  style="border: none"
  allowfullscreen></iframe>

Make sure to use the url-encoded value we produced, not the original resourceUri field!

During testing it is nice to use Draft as the Wordpress post's status: especially if you are targeting a semi-public blog. Once you've fine-tuned your integration you can choose to switch over to Published mode for a fully automatic setup.

Look through the rest of the fields and check if there is anything else you would like to change. When done submit the form with the Continue button and press Send test to WordPress on the next page.

Whitelisting iframes in WordPress

By default, WordPress filters HTML tags quite aggressively. The iframe tag needed to embed a Bambuser player is not allowed (opens new window) unless you whitelist (opens new window) it (opens new window).

This can be done by adding the following snippet to theme/functions.php or to a custom plugin.

Security

You should probably not enable this if you allow untrusted people to edit the blog posts on your site.

add_filter('wp_kses_allowed_html', 'allow_iframe_func', 10, 2);
function allow_iframe_func($allowedposttags, $context){
    $allowedposttags['iframe'] = array(
        'id'=> 1,
        'class'=> 1,
        'style' => 1,
        'src' => 1
    );
    return $allowedposttags;
}

In other words, this requires a WordPress host that allows you to edit your php files directly. On wordpress.com (opens new window) for example, a business plan is required.

Alternatives

Need even more control? You can also emit the webhook events to your own server or to a Google Cloud- or AWS-hosted cloud function and react with custom code.