API overview

The ioX-Pulse public API lets your own applications read device data out of ioX-Pulse and act on your fleet: dashboards in a BI tool, a customer-facing portal, a mobile app, a scheduled export, or a system that sends downlinks to devices. It is a versioned REST API under /api/v1, served from the same domain you use to sign in.

note

Where to find it: Sidebar → Account settings → Integrations tab. That is where you create and manage the API keys your applications use.

Two ways to integrate

There are two complementary ways to get data out of ioX-Pulse:

Approach	What it is	Best for
Pull (this REST API)	Your application asks ioX-Pulse for data, or sends a command, when it needs to.	History, exports, ad-hoc reads, and sending downlinks.
Push (webhooks)	ioX-Pulse sends each event to your endpoint as it arrives.	Real-time and latest-value use cases.

Both are available today. Use webhooks for anything that needs the latest value in real time, and the pull API for history, exports, and ad-hoc reads.

Do not poll for the latest value

It is tempting to call the latest-value endpoint on a timer to keep a screen fresh. Avoid that pattern where you can. Most polls return data you already have, it scales badly, and it burns through your request quota.

Two things make polling unnecessary or cheap:

• Conditional requests. The latest-value endpoint returns an ETag. Send it back on your next request as If-None-Match and ioX-Pulse answers 304 Not Modified with an empty body when nothing has changed. See Rate limits and quotas.
• Webhooks. Subscribe once and receive each new reading as it lands, with no polling at all.

Build a sign-in for your own app

If you are building a customer-facing app, such as a white-label mobile app, on top of ioX-Pulse, a sub-account-scoped key can also manage that sub-account's members: validate a sign-in, list the team, add a member, and remove one. This lets your app handle its own sign-in screen against ioX-Pulse without sending users to the portal. See Members.

Base URL and versioning

Every endpoint lives under /api/v1 on your ioX-Pulse portal domain. For example, if you reach ioX-Pulse at https://portal.example.com, the API base is:

https://portal.example.com/api/v1

The v1 prefix is a stable contract. The in-app interface can change without breaking your integration, and any breaking change to the API would ship under a new version prefix.

The interactive reference

A live, browsable reference is built in at /api/v1/docs on your portal domain. It lists every endpoint with its parameters and lets you try real calls. Paste an API key into the prompt at the top to load it and authorize the "Try it out" buttons.

The same description powers a machine-readable OpenAPI document at /api/v1/openapi.json (it requires a valid key), which you can feed into code generators and API tooling.

Next steps

1. Authentication: create an API key and learn how scopes work.
2. Endpoints: the available reads and writes, with copy-paste examples.
3. Webhooks: receive events as they happen instead of polling.
4. Rate limits and quotas: staying within your plan and polling efficiently.