At its core, IoT is all about data: data from devices, commands to devices, integrating IoT data with other data to gain insights. The data sources include devices, enterprise applications, vendor/partner systems, service providers and customers. The point-to-point integration between these various systems is not feasible; hence, APIs become the primary means of communication between these disparate systems. A clean architectural approach is the one suggested by the agile integration concept. APIs are central to this concept, which allow data to be shared securely between internal and external systems. The opening of APIs enables a company to provide uniform data and transaction interfaces to internal and external developers, partners, and customers, for improved data access and control of remote resources. By providing well-defined APIs, developers can use data in a programmatic manner; e.g., app developers can get access to IoT devices data without worrying about the underlying hardware interfaces. Considering the importance of APIs for IoT, it’s imperative for an organization to manage these APIs effectively. In fact, APIs have been called a fundamental enabler of IoT however, without an effective API Management solution, API sprawl can easily lead to catastrophe.

API management provides consistency of APIs across various apps, use cases and stakeholders. In addition, monitoring of the APIs can discover abnormalities across use conditions so corrective actions can be taken in real time.

Components of API Management

The most visible aspect of an API management solution is an API gateway that listens to the API traffic. It is a highly scalable, high throughput, low latency, reverse proxy server; e.g. Nginx. The gateway can be located on-premise or in the cloud and should ideally be co-located with the API back-end.

The less visible but equally important components of an API management solution are security features, usage policies like rate limiting, analytics and reporting, a developer portal, and monetization.

In order to support systems with differing capabilities, a wide range of security enforcement, access management, and governance methods needs to be supported; e.g. API key, tokens, OAuth, or external identity management like OpenID Connect that can hold master identity or act as a broker to various social or enterprise logins (like Google, LDAP, Active Directory, and Kerberos).

Using unauthenticated APIs can cause loss of private data or lead to security/safety issues as the Nissan Leaf API hack demonstrated. The Nissan Leaf car app only used the VIN (vehicle identification number) to invoke various services offered by connected car. Consider the risk if the similar methodology -- i.e. unauthenticated API access to backend -- is used to control the car’s operations or some other critical piece of IoT infrastructure. Therefore, access to all IoT devices, even those inside a company’s firewall, should be governed by well-defined security policies. Specifically, using standardized security and governance policies across the entire company, enabled by API management, can help avoid insecure API access.

Companies should be able to set different levels of access and rate limits for various classes of  users, device types or data types. This provides another layer of security enforcement to the IoT infrastructure, for example, if a compromised device starts sending unusual amount of data as in the case of a DDoS (distributed denial of service) attack. The infected devices can be quickly identified, isolated, and taken off the network before affecting the overall system. Considering a lot of IoT devices lack security mechanisms and are not updated regularly, it’s prudent for these devices not to be directly accessible without API gateway acting as a firewall.

Analytics and reporting provide the ability to track and monitor API usage and take action as users reach critical thresholds. This can all help determine which APIs and endpoints are more popular and which ones aren’t being used. Monitoring API usage allows for monetization so the consumers can be charged for API access or actual consumption.

A developer portal provides a place to register for APIs, retrieve API credentials, including API keys, get API documentation, and monitor API performance. The access to systems and devices by developers can be updated dynamically through the lifecycle of the project, such as granting full access to IoT devices during development phase and then restricting their access once the devices are deployed in production.

Important Considerations

To prevent a single point of failure, an API management solution should be distributed, highly scalable, and deployable in multiple environments (on-premise and cloud).  It should enable separation of policy management from control nodes. To enable desired agility, the solution should also allow for automation using popular open source tools like Ansible, Puppet, and Chef.

For time-sensitive IoT data, the latencies should be kept  minimal by use of local caching API key/tokens at the API gateway so the call can pass straight through to the API. The API policy manager can be called asynchronously for compliance with SLAs. This approach can support the high performance, low latency solution needed for IoT use cases.

In terms of adding additional capabilities to the gateway such as protocol adapters, the preferred approach should be keeping these functions (data integration, mediation or transformation) implemented separately, in an integration layer behind the API Gateway  using open source projects like Apache Camel or Red Hat Fuse as the productized version.

An example of API management deployed in an IoT use case is the Eclipse IoT Working Group’s Kapua project. Kapua exemplifies how open source-led innovation is enabling services required to manage IoT gateways and edge devices. It not only provides a core integration framework but also a set of core IoT services including a device registry, device management services, messaging services, data management, and application enablement. For integration with existing applications, Eclipse Kapua provides a REST API that exposes all the platform functionality.

The REST API also offers a bridge to the MQTT broker enabling the routing of commands from applications to devices without a specific connection to the message broker. Technologies such as REST/Comet/WebSockets are included, allowing real-time display of data published by the devices in web pages and mobile dashboards.

By using an API management approach, the Eclipse Kapua services can be offered to the public through API gateway. Using the agile integration approach, the whole solution can be offered as a set of containerized microservices. Using a container orchestration platform like Kubernetes can add the benefit of auto-scaling these resources as the IoT deployment grows.


APIs have been a key enabler of digital enterprise and one of the key capabilities of the agile integration concept. Popularized by often-used web services like Google maps, APIs are the foundation of our interaction within digital world. Fast-paced and adaptive solutions like IoT can benefit from agile integration through its use of modern platforms, processes, and technologies. APIs become the primary means of communication between disparate IoT systems across internal and external developers, partners, and customers. Considering the importance of APIs for IoT, it’s imperative for an organization to manage these APIs effectively using an API management solution like Red Hat 3scale API Management.

Some guidelines to keep in mind: The API management solution should be distributed, highly scalablen and deployable in multiple environments.  It should enable separation of policy management from control nodes. For time sensitive IoT data, the latencies should be kept to a minimum by the use of local caching of API key/tokens at the API gateway so the call can pass straight through to the API.

To learn more about the architectural concept of agile integration, check out our Digital Innovation Through Agile Integration whitepaper.

About the author

Deon Ballard is a product marketing manager focusing on customer experience, adoption, and renewals for Red Hat Enterprise Linux. Red Hat Enterprise Linux is the foundation for open hybrid cloud. In previous roles at Red Hat, Ballard has been a technical writer, doc lead, and content strategist for technical documentation, specializing in security technologies such as NSS, LDAP, certificate management, and authentication / authorization, as well as cloud and management. She also wrote and edited the Middleware Blog for Red Hat and led portfolio solution marketing for integration and business automation.

Read full bio