REST API

The IOTMER REST API gives you programmatic access to everything in the platform — devices, MQTT config, billing, workspace management, authentication, and provisioning.

Base URL

https://console.iotmer.com/api/

API reference

The full specification and interactive explorer live in the API section of this site (generated from the OpenAPI description). Groups worth noting: Device provisioning (POST /provision/device), Device HTTP API (device token only, e.g. POST /devices/auth/bind-claim), and Mobile app (moid) (end-user session, claims, bound devices—POST /moid/session may omit workspace_id for a global session).

See also API Authentication for how JWT, API keys, iotmer-auth-code, moid tokens, and device_http_token differ.

Capability definitions on device templates

Template create/update payloads include capability_definitions. In the OpenAPI schema this field uses CapabilityDefinitionsPayload — it documents exactly what the API accepts on the wire (including alternate shapes during migration). Automation and SDKs must follow openapi/v1-customer.yaml and whatever the deployed backend validates.

The Capability definitions product page describes only the canonical { spec_version, capability_definitions } envelope for modeling behavior — it does not duplicate union variants; keep OpenAPI and backend behavior aligned.

Request format

All requests use JSON:

Content-Type: application/json
Accept: application/json

Pagination

List endpoints are paginated:

GET /workspaces/{id}/devices?page=1&page_size=50

Response includes total, page, and page_size fields.

Error format

All 4xx/5xx responses follow RFC 7807 Problem Details:

{
  "type": "https://console.iotmer.com/api/v1/problems/not-found",
  "title": "Not Found",
  "status": 404,
  "detail": "Device 01J... not found in workspace",
  "trace_id": "abc123"
}

The trace_id field is useful when reporting issues to IOTMER support.