The Flowplayer API Overview

BY DAVE MERCER

Integrating Flowplayer via the Flowplayer API

Reading this, you’re undoubtedly familiar with Flowplayer. Flowplayer is software that plays your video content to viewers on your Website.

And if you are responsible for making Flowplayer work broadly across your organization, you may want to go beyond the most basic use case of video playback on your Website. With a little imagination, you will find many workflows inside your organization that benefit from integrating Flowplayer into them.

This article covers the high points of finding internal workflows and applications that expose potential for significant cost reduction, increased engagement, improved communications, and more, as well as laying out a roadmap for what you’ll want to do once you’ve found these worthwhile hidden gems.

Finding the Best Candidates

Good candidates are tasks/processes that are fairly simple but a lot of people are doing these tasks now and then. This goes for tasks/processes that are both frequent (saves a lot of time in total) and less frequent (people forget how to do the task and need some help).

So it’s best to start with a list of characteristics that tell you a particular workflow or application is worth investigating.

For example, here is a list of workflow traits that can drive your search:

1. Large amounts of time spent on completing a given task, and you want videos to become available at points in the process where employees typically get stuck.

2. Frequent mistakes or complaints about an internal application, and you want to allow users to make short videos and upload them with a support ticket, so the support team can debug the issues more quickly by viewing the video.

3. Prospects frequently dropping off at a specific point in the purchase process, and you want to offer an explanatory video to find out if the video can help close the deal.

4. You want to White Label and resell services from Flowplayer under your own brand. Of course you can always add more workflow characteristics to help you find the low-hanging fruit. And it helps to enlist the people that use the existing workflows every day, since they often know every bug or obstacle that needs attention.

First Flowplayer Integration Project

Once you’ve decided on the best candidate workflows, pick one that is somewhat inconsequential, easy to code, and easily debugged. The reason is, your technical team (or person) should not be forced to fix other fundamental issues with the workflow while they code and debug the Flowplayer integration.

Instead, their first Flowplayer integration project should be highly likely to succeed. Remember, even experienced programmers need to not only know how to integrate third-party services using a REST API, they need to learn about both the Flowplayer API and the internal workflow you are trying to improve.

This first Flowplayer API integration project is a learning experience for them, and unless they already have intimate knowledge of exactly how the internal process works in practice, they may run into obstacles that could have been avoided if they started by integrating a simpler workflow.

Only then can they build a mental map of how the Flowplayer API is used to implement the integration between your internal workflow and the workflow of using Flowplayer services, and only them can they be highly successful coding, testing, debugging, and releasing this new feature.

Oftentimes, one of the best ways to ensure a successful first project is to pair the lead developer with a Subject Matter Expert (SME), meaning a user who is very familiar with how the task or process works in practice. In my experience, there’s nothing so beneficial as finding and working with a person who has been on the job and using the selected workflow for a year or more.

Another important quality in an SME is that they are eager to share what they know in order to make the workflow smoother and more productive for everyone. Sometimes people may feel that any change in the workflow could force them to go through another steep learning curve, make their job less valuable to the company, or have a negative impact on their place in the company. A good developer knows how to counter these suspicions and perceptions when finding a suitable SME.

Lastly, everything about this first effort should be documented, including mistakes, dead-ends, obstacles, and the solutions that ultimately made the project successful. Clear documentation will help the developer (and anyone else who joins the integration team) with the next integration project.

Rest APIs

I’ve always liked the name “Rest API” simply because it sounds relaxing. A Rest API is truly nothing more than what we use everyday browsing the Web, but makes powerful use of the common URL structures and submission methods built into the HTTP protocol.

If you’re old enough to remember the early days of the Internet last century (sounds a lot older when put that way, doesn’t it), you’ll remember having to enter “http://www.whatever.com" in the address bar of your browser (do you remember Netscape browser?).

So HTTP is actually the main Internet Website protocol that has gone through a few iterations over the years, but is essentially the way things get done between various resources such as Websites, mobile apps, and more. It’s not the only protocol available, but we all know and use it.

There are two common ways data can be sent across the Internet with the HTTP protocol - GET and POST. GET means adding more parameters to the URL you are entering, while POST uses HTTP with forms, like when you fill out an application for a loan online.

One thing to point out now - you may be wondering why I didn’t mention HTTPS already. The reason is, both HTTP and HTTPS are really the same protocol, but the “S” in HTTPS just means additional security is added by encrypting the data in the URL as it passes from your computer to a Website, or from one online application to another. It’s good practice (and in most cases required) to use HTTPS for all API Calls. So on with the basics - GET and POST are two HTTP “verbs”, meaning words that indicate an action is to be done. There are also a few more common PUT, PATCH, and DELETE HTTP verbs, and even more that are not so common.

While there are extensive technical debates about when to use which verb, and there are ways you can use some of them interchangeably, the bottom line is, it’s best to conform to Rest API standards and use the right verb for each action you want to accomplish, if only so the next developer has an easier time maintaining your code.

So how does a Rest API work? Commonly, a third-party service (such as Flowplayer) will write code to expose “endpoints” to which your specially constructed URLs or form submissions can be sent, and there your URLs (we’ll call them API Calls form now on) securely transmit instructions and data to the endpoints so that the action you desire to have done by that third- party service actually gets done and a successful response is received.

One other main consideration is authentication, meaning a way to ensure that you are who you say you are, and you have appropriate permission to do the action you’re doing. There are several ways to accomplish authentication, and later in this series we will cover Flowplayer API authentication.

This is a highly simplified explanation of what Rest APIs are, so in case you’d like a bit more, here are some very good sources of further reading:

https://www.freecodecamp.org/news/rest-api-best-practices-rest-endpoint-design-examples/

https://booksoncode.com/articles/books-on-rest-api

What the Flowplayer API Does

The Flowplayer API is constantly ready for legitimate, authenticated API calls to come in, be processed, and return the appropriate values and messages.

The complete reference to the Flowplayer API V3 (3.0.0) can be found here: https://docs.flowplayer.com/platformapi/assetmanagement/platform-api-reference-3

The Flowplayer Analytics API is similar but separate from the main Flowplayer API. It is documented here:

https://docs.flowplayer.com/analytics-api/getting-started

You can use these APIs to work with video-related assets such as Livestreams, Live Sources, Playlists, Categories, and Videos, and to get summarized analytics data for individual assets.

All calls to these APIs must be authenticated with the appropriate API keys in the header of the call, and use HTTPS in the URL. Be sure not to store the API keys in any front-end part of the application - only apply it in your back-end code so users cannot retrieve it.

Essentially, like almost all APIs, instead of your development team needing to create and maintain all the services provided by Flowplayer, you open an account and then simply “plug in” to Flowplayer’s backend via these APIs, and immediately you are able to use Flowplayer services inside your own online applications.

For each of these main types of video-related assets, you can fetch, list, create, update, and delete any of these assets that you’ve manually or programmatically created on the Flowplayer platform.

So let’s talk a little about the common types of actions you can take for managing your Flowplayer assets, and a bit more detail about each asset type that can be managed with nothing more than an API Call.

First off, the actions you can perform with the majority of these API Calls include List, Create, Get, Update, and Delete. They’re pretty self-explanatory, and somewhat familiar to the traditional Create, Read, Update, and Delete (CRUD) operations most any application or database can do.

The main difference is, List means retrieve one or more assets, and Get means to retrieve a single asset. Both of these actions are encompassed by the Read operation in CRUD. The rest do exactly what they say, and that’s often all you need.

Now we’ll discuss the asset types you can work with using the Flowplayer API.

Live Streams and Live Sources

Live Streams and Live Sources are quite similar, but Live Sources are unique to Flowplayer in that Live Sources are essentially a Live Stream whose set up can be reused multiple times from different sources.

The benefit of using Live Sources becomes apparent when you want to preserve the analytics and configuration even if you have several different sources broadcasting. The downside is, you won’t necessarily gain the optimized encoding and delivery that the default Live Stream would.

Categories

Categories provide a simple and intuitive way to organize your Live Streams/Sources, Videos and Playlists, and related assets. Like most systems of categories, these categories can be Parents and Children, meaning you can have a main category with subcategories, similar to having folders and subfolders for your files.

Videos and Playlists

Unlike Live Streams, Videos are assets that have been stored in some location (often with Flowplayer storage and delivery services, but can be on your own CDN or other storage as you choose). In fact, you can set your Live Streams to be recorded and saved, and then do some production work on the saved files and re-upload them for delivery as Video-On-Demand (VOD). So while it’s definitely possible to manually perform these functions, your producers may have software that allows the use of Flowplayer API Calls to get the job done faster and smooth out that workflow.

Analytics

Flowplayer’s Analytics API typically requires the ID of the Video, Category, Workspace, Live Stream, and other assets, plus a few extra parameters to define the time period or other measurement and summarization dimensions you are seeking to retrieve for an asset.

The Analytics API response includes (for example for videos) summarizes analytics data such as number of displays, number of plays by device, engagement (duration, average seconds viewed, total seconds viewed, and so on).

Postman: A Handy Tool for Working with Rest APIs

Like any other type of coding, it’s easier to code and debug when you have some handy tools designed specifically for the job at hand.

One tool that is highly capable and frequently used for API Development is Postman. Postman gives you numerous ways to build the desired API Calls and run them to ensure the responses are correct given the parameters you’ve submitted.

In addition, Postman includes a handy code conversion feature that will convert what is essentially command line cURL calls into the same call using a variety of common coding languages. This is a big help to coders across the spectrum of coding languages.

Lastly, API Calls often need to obtain a session key after authenticating, then run the API Calls you are testing. Postman allows for session keys to be stored and reused in your API Calls in a realistic way, thus making it simple to run the API Calls being tested without resorting to cumbersome manual methods.

What is the Future of the Flowplayer API

Flowplayer is a bright, up-and-coming company growing rapidly, has an excellent product, and has talented teams in place for customer service, sales, technical support, and development of new products.

And I wouldn’t be surprised if the Flowplayer API continues to be well-maintained and also extended to cover additional services that are in the pipeline.

Flowplayer services and the Flowplayer API are a good choice for high-quality services now and into the future.