IoT Platform API: Connect Your Data to ERP, BI, and GIS

An IoTITermIoT (Internet of Things)The IoT (Internet of Things) is the network of physical objects with sensors, software and connectivity that collect and exchange data and act autonomously.View profile platform API decides whether sensor data stays on a dashboard or reaches the ERP, BI, and GIS tools where your client makes its decisions.

Sofía runs operations at a water utility that serves 60,000 homes. Two years ago, her integrator connected 9,000 smart meters and built dashboards that the control room likes. Then the monthly routine took over. On the first of each month, someone in finance exports a spreadsheet of readings and types the totals into the ERP. Every Friday, the GIS team downloads a CSV to update the leak map.

The meters are connected, the platform works, and the integration between systems is still two people copying data by hand.

This guide explains what an API-first IoT platform is, the three patterns for moving data out of it, and how to connect it to ERP, business intelligence (BI), and geographic information system (GIS) tools without breaking any of them. It's written for integrators and device manufacturers who deliver IoT projects into companies that already run other software. If you want a no-code starting point first, see how to connect Zapier to an IoT platform.

What an API-First IoT Platform Means

An API-first platform exposes its functions through documented interfaces that other software can call. The screens are one client of those interfaces, and your integrations are another. Anything a user can do by clicking, a program can do by calling.

In practice, a useful IoT platform API covers four areas:

• Data. Current values, history, alarms, and events.
• Configuration. Devices, locations, users, and alarm rules.
• Commands. Setting a value or sending an instruction to a device.
• Structure. The hierarchy of clients, sites, and assets, so external systems know what each device belongs to.

What to Check Before You Promise an Integration

A sales deck that says "open API" tells you little. Before you commit to an integration in a proposal, look for:

1. Public documentation with examples, ideally in a machine-readable format such as the OpenAPI Specification.
2. Authentication with tokens that can be limited to specific permissions.
3. A way to fetch only what changed since the last call.
4. Outbound notifications, so the platform can call your system when something happens.
5. Clear limits on page size and request rates.

For a comparison of the two protocols you'll meet most often, read MQTT vs. REST for IoT.

Why It Matters to Integrators

Integration work is where many IoT projects earn their margin after installation. Each connection to an ERP, a BI tool, or a map is a piece of work the client values and rarely wants to build alone. It's also the question your client's IT department will ask first in a tender: how does the data get into the systems we already pay for?

A project with working integrations is also harder to replace. When meter readings flow into billing and alarms open work orders, the platform becomes part of how the client runs its business, which is a stronger position than a dashboard someone opens once a week.

Three Integration Patterns: Pull, Push, and Stream

Every integration with an IoT platform API uses one of three patterns, or a mix of them. Picking the right one for each flow avoids most performance problems.

Pull Without Downloading Everything

The most common mistake with pull integrations is asking for the full dataset on every run. A better design is incremental sync. The platform gives each new or modified record a sequence number that only grows. Your integration stores the highest number it has seen, asks for records above it, and repeats.

When the response comes back empty, there's nothing new, and the integration waits before trying again. When it's full, the integration processes the page and asks again straight away. Deleted or closed records come through the same channel with a flag, so the external system stays consistent without a nightly full reload.

The loop is short enough to write on a whiteboard:

last = load_checkpoint() # 0 on the first run
repeat:
page = get_records(after = last)
if page is empty:
wait 60 seconds
continue
process(page)
last = highest sequence number in page
save_checkpoint(last)

Save the checkpoint only after the page is processed. If the job stops halfway, it repeats a page instead of skipping one.

Push for Events That Need Action

Alarms are events, and they should travel as events. When a tank level crosses a threshold, the platform can send an HTTP request to the maintenance system and create a work order in seconds. Polling for alarms every ten minutes adds ten minutes to every response.

Design the receiving endpoint so that the same message processed twice produces the same result. Networks fail, and a retry after a timeout is normal.

A useful event message carries enough context to act without a second call: the event type, the device and site identifiers, the value that triggered it, the rule that fired, and the time in UTC. Add a unique event ID so the receiver can discard duplicates. Protect the receiving URL with a secret or token that only the platform knows, and reject anything that arrives without it. If the receiving system is down for maintenance, agree in advance whether events should queue, retry for a while, or fall back to an email so that nobody misses an alarm.

Stream for Live Data

When a screen has to update every second, a broker subscription beats both polling and webhooks. The guide to MQTT brokers explains topics, retained messages, and sessions.

Using the IoT Platform API With an ERP

ERP systems work with orders, invoices, assets, and cost centers. They don't need one reading per minute. The integration's job is to translate sensor data into the records the ERP already understands.

Send Business Records, Not Raw Readings

Back at Sofía's utility, the fix for monthly billing took three decisions:

1. Map every meter to its ERP record. The platform stores the ERP contract number as a device property, so both systems use the same key.
2. Send one reading per meter per billing period. A scheduled job pulls the last valid reading before midnight on the last day of the month, and posts it to the ERP.
3. Flag exceptions instead of guessing. Meters with no reading in the last 48 hours go to a review list, where the old process kept typing in estimates.

The finance team stopped retyping 9,000 numbers. The review list averages 40 meters a month, and each one is a real problem worth a visit.

From Alarm to Work Order

The second flow that pays off is maintenance. A sustained alarm on a pump, a compressor, or a waste container can open a service order in the ERP or in the computerized maintenance management system (CMMS). One common pattern uses robotic process automation: the alarm triggers a bot that creates the order inside the ERP with the same steps a person would follow, so the transaction is logged and audited. The guide to industrial IoT implementation shows where this fits in a plant rollout.

Where the Integration Logic Lives

The mapping between platform data and ERP records has to run somewhere. The usual options are an integration platform the client already owns, a small service written by your team, the ERP's own import tools, or a low-code flow tool such as Node-REDNTermNode-REDNode-RED is a flow-based visual programming tool to wire together devices, APIs and services, widely used in automation and IoT.View profile. Whichever you choose, keep the mapping in one place, log every message with its result, and give the client's IT team a way to see failures without calling you. An integration that only its author can debug turns into a support contract nobody priced.

Feeding BI Tools Without Breaking Them

BI tools are built to analyze tables, and they struggle with billions of raw readings arriving over HTTP. Three rules keep dashboards fast and API calls under control:

• Aggregate before you analyze. Most business questions need hourly or daily values: consumption per site, running hours per machine, alarms per week.
• Use a staging layer. An incremental job loads new data into a database or data warehouse, and the BI tool reads from there. Pointing a report straight at the live API means every refresh calls the platform again.
• Store time in UTC. Convert to local time in the report. Mixing time zones is the fastest way to lose an hour of data twice a year.

Late Data and Corrections

Devices on weak connections sometimes send readings hours late, and gateways with local buffers send them in bursts. An incremental sync based on sequence numbers picks up late readings, because they get a new sequence number when they arrive. A sync based only on timestamps misses them. Recalculate the aggregates for the affected days when late data comes in.

Planning an integration for a client's data team? The technical documentation describes the data extraction APIs in detail.

Putting Sensors on the Map: GIS Integration

City councils, utilities, and logistics companies think in maps. A GIS integration puts each device where it is and colors it by state.

Most GIS tools read GeoJSON, a format defined in RFC 7946 that uses WGS 84 coordinates in decimal degrees. Newer GIS servers also publish and consume data through OGC API Features, a standard web interface for geographic features. An integration usually needs:

• Fixed coordinates for static assets such as meters, containers, or streetlights, stored as device properties.
• Live positions for mobile assets such as vehicles, updated from GPS readings.
• Geozones, so the platform can raise alarms when an asset enters or leaves an area, and the GIS can draw the same boundaries.

A Map the Council Uses Every Day

Andrés works for an integrator that runs waste-container sensors for a council of 150,000 people. The operations team wanted fill levels on the map they already used for street cleaning, not on a separate dashboard. His team built a small job that pulls container states from the platform every five minutes and publishes them as a GeoJSON layer. The map shows each container in green, amber, or red, and the route planner reads the same layer.

Location deserves care. When a position can be linked to a person, such as a driver's vehicle or a worker's badge, it counts as personal data under the GDPR. Limit who can see live positions, keep history only as long as the purpose requires, and agree those rules with the client before the map goes live.

For smart citySTermSmart cityA smart city uses IoT sensors and data to manage urban infrastructure more efficiently and sustainably: traffic, lighting, waste and water.View profile projects in Europe, public tenders often ask for FIWARE compatibility. FIWARE's context API, NGSIv2, and its linked-data successor NGSI-LD, let several city systems share the same entities. The guide to LoRaWAN for smart cities covers the network side of those projects.

Security and Reliability Checklist for API Integrations

An integration is a new door into the platform, and it needs the same care as a user account. The OWASP API Security Top 10 lists broken object level authorization as the first risk of 2023: an API that returns an object because the caller knows its ID, without checking that the caller may see it.

1. One token per integration. If the BI job leaks its token, you revoke it without stopping the ERP flow.
2. Least privilege. The BI token reads data. It doesn't create users or send commands.
3. Tokens in headers, not in URLs. The OAuth bearer token standard, RFC 6750, advises against passing tokens as query parameters because URLs end up in logs.
4. Respect pages and limits. Read in pages, and back off when the platform asks you to slow down.
5. Make retries safe. The receiving system should recognize a message it has already processed.
6. Monitor the integration. Alert when the sync falls behind or when a webhook starts failing. A silent integration looks exactly like a quiet day.

Test every integration against a staging environment with realistic data before it touches production. A mapping error that creates 9,000 duplicate invoices is easier to find with test records than with real customers. The guide to OT cybersecurity for industrial AI and IoT covers the network side of the same problem.

How Cloud Studio IoT Supports API-First Integration

Cloud Studio IoT exposes its platform through APIs that integrators use every day:

• REST APIs for data extraction, covering endpoint data, alarms, alert rules, geozones, and the client and site hierarchy, all with incremental sync by sequence number and pages of up to 500 records.
• Platform services to manage devices, dashboards, and commands.
• Token authentication with the same role-based permissions as the user interface, sent in the authorization header.
• Actions that can include an HTTP request step, so an alarm can call an external system as soon as it fires.
• A built-in MQTT brokerMTermMQTT brokerAn MQTT broker is the central server that receives messages from publishers and distributes them to subscribers by topic. Examples: Mosquitto, EMQX, HiveMQ.View profile for devices and live data.
• FIWARE compatibility, with data exposed through NGSI APIs, and a documented pattern for SAP Build Process Automation that turns physical alarms into audited ERP transactions.

AI assistants are another consumer of the same APIs. The article on MCP integration and IoT platforms shows how a language model can query platform data. For integrators who deliver under their own brand, these APIs work the same way on a white-label IoT platform.

Key Takeaways

• An IoT platform API is only useful if it covers data, configuration, commands, and structure, with documentation and scoped tokens.
• Use pull with incremental sync for reports, push for events that need action, and streams for live screens.
• ERP systems need business records such as billing reads and work orders, not raw readings.
• BI tools work best on aggregated data in a staging layer, with time stored in UTC and late readings handled.
• GIS integrations run on standard formats such as GeoJSON and OGC API Features, and on FIWARE's NGSI in many smart city tenders.
• Treat every integration like a user: its own token, least privilege, and monitoring.

If your client's systems are waiting for the data your devices already collect, see what the IoT platform includes, or talk to the team and bring the list of systems you need to connect.