API Platform for IoT Development

TL;DR

IoT APIs have characteristics that break standard API tool assumptions: constrained bandwidth, binary payloads, device authentication patterns, and protocols that aren’t HTTP at all. This article covers what IoT developers need from API tooling, where standard tools like Apidog fit, where they fall short (MQTT is the honest example), and how to test the HTTP-facing layer of your IoT backend effectively.

Introduction

IoT development has a split personality when it comes to APIs. On one side, you have the device-facing communication layer: MQTT brokers, CoAP endpoints, custom binary protocols, and WebSocket streams. These protocols are chosen for bandwidth efficiency, low power consumption, and suitability for constrained networks.

On the other side, you have the platform-facing layer: REST APIs for device provisioning, firmware update delivery, telemetry ingestion, and management dashboards. These look like any other web backend.

Most API tools serve the second group well and ignore the first entirely. That’s a real gap, but it’s also the honest reality. An IoT developer who expects a general API platform to handle MQTT testing natively will be disappointed. The right approach is to understand which protocols your standard API tool covers, use it effectively for those, and know where to reach for specialized tools.

This article maps the IoT protocol landscape, explains what Apidog covers (and what it doesn’t), and gives you a practical testing setup for the HTTP-facing portions of your IoT backend.

The IoT protocol landscape

MQTT: publish-subscribe for devices

MQTT is the dominant protocol for device-to-cloud communication. It’s designed for unreliable networks, constrained devices, and efficient message routing through a broker.

Key MQTT concepts: topics (hierarchical message channels), QoS levels (fire-and-forget, at-least-once, exactly-once), retained messages, last will and testament (LWT) for offline detection.

Apidog does not support MQTT natively. For MQTT testing, use:

• MQTT Explorer: Desktop GUI for MQTT broker interaction
• MQTTX: Cross-platform MQTT client with scripting
• mosquitto_sub/mosquitto_pub: CLI tools from the Mosquitto project
• HiveMQ Broker (free tier): Cloud MQTT broker with a built-in web client

If you’re building an MQTT-based IoT system, budget time for a dedicated MQTT testing tool alongside your REST API tool.

HTTP/REST: the platform layer

Every IoT platform has a REST API surface, even if devices don’t use REST for telemetry. REST handles:

• Device provisioning: Registration, certificate generation, identity assignment
• OTA firmware updates: Checking for updates, downloading firmware packages
• Configuration push: Sending configuration data to devices or device groups
• Telemetry ingestion: Some IoT platforms accept telemetry over HTTP POST (AWS IoT, Particle, many others)
• Device management: Fleet status, remote commands, device grouping
• Data query: Historical telemetry, event logs, alert history
• Webhook registration: Configuring outbound event delivery to your application

This entire surface area is testable with standard REST tools.

WebSocket: bidirectional device communication

WebSocket sits between REST (stateless, request-response) and MQTT (broker-mediated, publish-subscribe). Some IoT platforms use WebSocket for:

• Device command streams (real-time command delivery to a connected device)
• Live telemetry display (streaming sensor data to a management UI)
• Bidirectional configuration updates

Apidog supports WebSocket testing with connection header support, which covers most WebSocket-based IoT scenarios.

CoAP: constrained devices

CoAP (Constrained Application Protocol) is an HTTP-like protocol designed for microcontrollers and very constrained networks. It runs over UDP rather than TCP.

Apidog does not support CoAP. For CoAP testing, use copper4cr (browser extension) or libcoap CLI tools.

Binary payloads

Many IoT protocols use binary encoding rather than JSON: Protocol Buffers, MessagePack, CBOR, or custom binary formats. Binary encoding is essential for bandwidth-constrained scenarios where a sensor is sending thousands of readings per day over a metered cellular connection.

Apidog supports raw binary request bodies. You can send hex or base64-encoded binary payloads in HTTP requests, which covers the cases where your IoT platform accepts binary over HTTP.

Device authentication patterns in IoT

Authentication for IoT devices is different from typical web API authentication. General-purpose API tools support OAuth 2.0, Bearer tokens, and API keys, but IoT adds:

Mutual TLS (mTLS)

Many IoT platforms (AWS IoT Core, Azure IoT Hub, Google Cloud IoT Core) use mutual TLS for device authentication. Each device has a client certificate issued during provisioning. The device presents this certificate when connecting.

Testing mTLS endpoints requires loading a client certificate and private key. Apidog supports client certificate configuration for TLS connections, so you can test mTLS endpoints by loading your device certificate files.

Device-specific API keys

Simple IoT platforms often issue per-device API keys or token pairs. These work like standard Bearer tokens or API key headers, which Apidog handles natively.

JWT with device claims

Some platforms issue JWTs with device-specific claims (device ID, model, firmware version). Standard JWT Bearer auth works here. Pre-request scripts can handle token refresh if tokens are short-lived.

Custom header auth

Some proprietary IoT platforms use non-standard authentication headers. Apidog supports arbitrary custom headers, so platform-specific auth headers like X-Device-Token or X-Device-Serial are straightforward.

Testing IoT REST APIs with Apidog

Here’s where Apidog delivers real value for IoT backend development.

Device provisioning flows

IoT provisioning is often a multi-step REST flow:

1. Request device registration (POST with device serial, model, firmware version)
2. Receive device ID and credentials in the response
3. Configure the device with the received credentials
4. Verify registration status (GET device status)

Apidog’s chained request support makes this testable end-to-end. A post-request script on step 1 extracts the device ID and stores it as an environment variable. Step 3 uses that variable in the request URL. The full provisioning flow runs as a sequence.

OTA firmware update endpoints

OTA update flows typically involve:

1. GET /devices/{id}/update-check – returns whether an update is available
2. GET /devices/{id}/firmware – returns the firmware download URL or binary
3. POST /devices/{id}/update-status – reports installation result

Testing these with Apidog is straightforward. For the firmware binary response, you can inspect headers (Content-Type, Content-Length) and verify the response is the expected binary format.

Telemetry ingestion via HTTP

Many platforms accept telemetry over HTTP POST. The payload might be JSON, but increasingly it’s binary (Protocol Buffers, MessagePack) for bandwidth efficiency.

To test binary telemetry ingestion with Apidog:

1. Set the request body type to raw
2. Select binary as the body format
3. Paste your hex or base64-encoded payload
4. Set Content-Type: application/octet-stream (or your platform’s expected type)
5. Send and inspect the response

For protobuf payloads specifically, you’ll need to encode your test payload using a protobuf library before pasting it into Apidog. The tool doesn’t have built-in protobuf encoding, but it handles the transport correctly.

Testing with custom SSL certificates

IoT backends often run on private networks with self-signed certificates, or use certificate pinning. Apidog’s SSL settings let you:

• Disable SSL verification for local development (self-signed certs on dev servers)
• Load a custom CA certificate for validating a private CA
• Load a client certificate for mTLS testing

For dev environments with self-signed certificates, disabling SSL verification gets you unblocked immediately. For production testing, load your CA certificate to validate the server’s cert properly.

WebSocket testing for IoT device streams

IoT platforms increasingly offer WebSocket endpoints for real-time device communication. Common use cases:

Device shadow / twin streams: Some platforms (AWS IoT, Azure IoT) provide WebSocket endpoints that stream device shadow updates. When a device reports state, the cloud reflects it through a WebSocket connection to subscribed clients.

Live telemetry streams: Real-time sensor data display dashboards connect via WebSocket to a telemetry streaming endpoint.

Command delivery: Some platforms deliver real-time commands to online devices over WebSocket rather than waiting for the device to poll.

Testing these with Apidog’s WebSocket client:

1. Connect to the WebSocket URL with required auth headers (usually a Bearer token or API key)
2. Send a subscription message if the protocol requires it (e.g., subscribe to a device’s event stream)
3. Observe the incoming message stream in the message log
4. Send test command messages and verify device-side behavior

For platforms that use subprotocols (Sec-WebSocket-Protocol header), Apidog supports specifying subprotocols in the connection configuration.

What to use for MQTT testing

Since Apidog doesn’t support MQTT, here’s a practical MQTT testing setup:

MQTTX is the most capable general MQTT client. It has a desktop GUI, supports all MQTT protocol versions (3.1.1 and 5.0), handles TLS/mTLS connections, and includes a scripting mode for automated message sequences. For interactive MQTT testing, MQTTX is the best starting point.

MQTT Explorer is simpler and excellent for browsing topic trees visually. If your main need is understanding what messages are flowing through a broker, MQTT Explorer makes that visible.

mosquitto CLI tools (mosquitto_pub, mosquitto_sub) are available on most development machines (via package manager) and work well for quick scripted tests. If you need to pipe test data into an MQTT topic or subscribe and log incoming messages, the CLI tools are often faster than a GUI.

For CI/CD integration, custom test code using a language-native MQTT library (paho-mqtt for Python, MQTT.js for Node) is the most flexible approach.

Practical IoT backend testing setup

Apidog environment structure:

Environments:
  local-dev: base_url = http://localhost:8080, ssl_verify = false
  staging: base_url = https://iot-staging.example.com, ssl_verify = true
  prod: base_url = https://api.iot.example.com, ssl_verify = true

Variables:
  device_id = dev_test_001
  device_serial = SN-TEST-00001
  auth_token = {{fetched via pre-request script}}
  firmware_version = 2.1.4

Folder structure:

• provisioning/ – device registration and credential issuance flows
• telemetry/ – ingestion endpoint tests (JSON and binary variants)
• ota/ – firmware update check and delivery flows
• device-management/ – CRUD operations on device records
• websocket/ – real-time connection tests
• error-cases/ – invalid credentials, expired tokens, malformed payloads

Binary payload testing checklist:

• Test with valid binary payload (happy path)
• Test with truncated binary payload (incomplete message)
• Test with wrong Content-Type header
• Test payload size at your platform’s documented maximum
• Test with correct and incorrect device authentication

FAQ

Does Apidog support MQTT testing?No. Apidog does not have native MQTT support. For MQTT testing, use MQTTX, MQTT Explorer, or the mosquitto CLI tools. Apidog covers the HTTP and WebSocket layers of your IoT backend, not the MQTT broker layer.

Can Apidog test CoAP endpoints?No. CoAP runs over UDP, which Apidog does not support. For CoAP testing, use copper4cr or libcoap.

How do I test binary protobuf payloads in Apidog?Encode your protobuf message to binary using your language’s protobuf library, then convert to hex or base64. In Apidog, set the body to raw binary and paste the encoded payload. Set Content-Type to application/protobuf or whatever your platform expects.

Does Apidog support mTLS for device certificate authentication?Yes. Apidog’s SSL settings allow you to load a client certificate and private key for mTLS connections. This covers testing endpoints that require device certificate authentication.

Can we use Apidog to test AWS IoT Core, Azure IoT Hub, or Google Cloud IoT?Yes, for the HTTP REST APIs of these platforms. AWS IoT Core has REST management APIs, Azure IoT Hub has REST endpoints for device management and direct method invocation, and Google Cloud IoT Core has REST APIs. All are testable with Apidog. MQTT connections to these platforms require MQTTX or similar.

What’s the best approach for testing low-bandwidth binary telemetry encoding?Create test fixtures of known binary payloads (valid, truncated, malformed) using your encoding library. Store these as environment variables or test files. Use Apidog to send them to your ingestion endpoint and verify the response codes and processing behavior.

IoT backend development spans protocols that no single tool covers completely. The honest answer is that you need at least two tools: something for MQTT testing and something for REST/WebSocket. Apidog handles the HTTP layer thoroughly – provisioning, management, telemetry ingestion, binary payloads, mTLS, and WebSocket streams. For MQTT, MQTTX or mosquitto fills the gap. Knowing which tool to reach for and when is more useful than pretending one tool covers everything.