Overview

This documentation covers Device API version 1 (denoted by v1 in every API URL). The core API contract is stable, but small refinements ship periodically. To keep older firmware working, every Device Model carries a Xyte API Version that controls exactly how the platform responds to that Model's Devices.

Version management

When a Device Model is created, the Xyte API Version is set in one of three ways:

First Device Model — defaults to the highest supported version.
Subsequent Device Models — defaults to the highest version among the Partner's existing Device Models. This ensures that firmware already deployed on other Device Models continues to work for the new one.
Manual selection — the Partner can override the default in the creation dialog. The latest version is recommended for new development.

To change the Xyte API Version after a Device Model has been created, contact Xyte support.

Change Log

v1.0.7 (latest)

Added the device_id field to be returned by the following APIs (HTTP & MQTT)

v1.0.6

The Update Device API accepts only supported parameters and returns an error 400 if an unknown parameter was passed.

v1.0.5

The Get Config API and Set Config APIs return the configuration scoped instead of merged with server parameters

{
  "version": 10,
  "last_updated": ....,
  ..configuration fields..
}

{
  "name": ...,
  "version": ...,
  "last_updated": ...,
  "config": { ..configuration fields.. }
}

v1.0.4

Require firmware versions to be in the Semantic Versioning format.

v1.0.3

The hub_url parameter returned by Register Device API and Register Child Device API, must be used for all following communications with the server, instead of entry.xyte.io

v1.0.2

The Register Device API requires the sn (Serial Number) parameter, even when using “CloudID” Device Authentication.

V1.0.1

The Update Command API now requires the original command's ID to be passed as the id parameter. (Previously it automatically references the command at the head of the queue).

Model API Version