Core API: Commands, Rate Limits & Device State

Answers to common questions about driving devices programmatically through the Core API — command execution, rate limits, reading device state, and how long state history is kept. For the command payload format, see Commands.

Is programmatic command execution included, and are there usage limits?

Running commands through the Core API is part of your org's standard access — there's no separate tier to enable. There are no usage limits on the command APIs beyond the platform's general abuse/DDoS protection.

📘

Short answer

Included. No limits on the command APIs beyond abuse detection.

What are the API rate limits, per org and per device?

There are currently no published per-org or per-device rate limits. The platform performs only minimal detection aimed at major abuse. In practice you won't hit anything unless you poll a single endpoint multiple times per second — keep automated scripts below that and you'll stay well within bounds.

📘

Short answer

No formal limits today — only minimal abuse detection. Stay under multiple calls per second to the same endpoint.

Can I subscribe to device state changes, or do I have to poll?

Today, polling is the supported way to read device state — there is no webhook or push channel for state changes yet. If a push model matters for your use case, tell us what you're building; the right approach depends on what you need the state for.

📘

Short answer

Polling only, for now. No state-change webhooks/push yet.

Queued commands are picked up in ~10 seconds. Is that interval fixed?

No — command pickup latency is determined by the device, not by a fixed platform interval. It depends on how often the device sends telemetry, or whether it maintains an MQTT connection. Devices on a tighter telemetry cadence, or connected over MQTT, pick queued commands up faster. There is no single global setting that changes this.

📘

Short answer

Device-dependent (telemetry cadence / MQTT) — not a global setting.

How long is device state history retained, and can I bulk export it?

Device state history is guaranteed for 3 months. Retrieve it programmatically with the Get Histories endpoint.

📘

Need a full one-time export?

A complete historical download isn't a self-serve endpoint — contact Xyte and it can be produced manually.

Are there limits or a review step for commands with dynamic parameters?

There are no limits and no review step on model commands with dynamic parameters. The only caveat is presentation: very large parameter sets can render awkwardly in the UI — for example 10 or more parameters, or a select dropdown with thousands of options.

🚧

Heavy parameter sets

If your command has 10+ parameters or a dropdown with thousands of options, reach out so the UI handling can be worked through with you.