Adding a REST API to OTA Connect

Photo of Andy Doan

Posted on Aug 9, 2018 by Andy Doan

2 min read

The OTA blog series left users with a secured OTA Connect server. This article will describe how you can deploy an easy-to-use REST API to manage your devices.


You'll need an OTA Connect service deployed into GKE as documented in part four of the blog series.


While OTA Connect is built around a set of backend REST APIs, they don't include a unified front-end API designed for public facing usage. We created the OTA API with the goal of making a project that handled all the generic aspects of OTA device management while leaving room for people to implement their own management policies.

The OTA API is easy to try out locally. Follow along with the README to test things out before deploying to production.


Go to your OTA Community Edition deployment repository that should be on the ota-blog-part4 branch and checkout the ota-api-1 branch:

  cd <repo>
  git fetch
  git checkout ota-api-1

The interesting changes to enable the API are in a single commit. It creates a new "" endpoint that requires the BadT0ken5 used in the "oauthful" container. It can be deployed by running:

  ./contrib/gke/make start-services

You can then validate the API is running with:

  curl -H "OTA-TOKEN: BadT0ken5"

Next Steps

You'll probably want to customize things to match your organization's requirements. For example, limit how many devices a user can create or which devices a user can see. The ota-api-1 branch includes a commit to give you some ideas about what to change. As your complexity increases, you'll likely want to build your own OTA API container. There are different approaches that work. Here at, we extend the "foundries/ota-api" container and add our private implementation sources to produce a customized container.

Lastly, I'll be creating a follow-up blog to this to demonstrate how to streamline device registration by extending this API.

Related posts