How to get data from my machines to a dashboard?

A monitoring dashboard is often just the starting point. Once machine data is being reliably collected, the next question is usually how to get it into whatever else the business already runs on – an ERP system, a custom BI tool, an internal application, a data warehouse. That's what an API is for. This article covers how machine data typically gets exposed through an API, what's usually available, and what to plan for before building an integration against one.

Contents:

1. What API access means in this context
2. Common API patterns
3. What data is typically available
4. Authentication and security
5. Common integration use cases
6. Practical steps to build an integration
7. Common pitfalls
8. Frequently asked questions
9. Conclusion

What API access means in this context

It's worth separating two layers that both get called "APIs" in machine connectivity conversations. There's the machine-facing layer – the protocols covered elsewhere on this blog, like MTConnect, OPC UA, or FOCAS, used to pull data out of a controller. And there's the platform-facing layer: the API a monitoring platform exposes so that other software can pull already-collected, already-processed data back out of it. This article is about the second kind – getting data that's already been captured and structured by a monitoring system into whatever custom system needs it next, rather than connecting to a machine directly.

Common API patterns

• REST APIs are the most common pattern: a custom system sends an HTTP request to a defined endpoint and receives structured data back (typically JSON), usually scoped by machine, time range, or metric type. This is a pull model – the requesting system decides when to ask for data.
• Webhooks invert that relationship: instead of a custom system asking for data, the monitoring platform pushes a notification the moment something specific happens – a machine going into alarm, a shift ending. We cover this pattern specifically in webhooks for real-time machine events.
• Bulk export / scheduled data dumps are a simpler pattern some platforms offer alongside a full API: periodic exports of data in a defined format, useful for systems that don't need real-time access but do need regular, structured data delivery.

Most integrations end up using more than one pattern – REST for on-demand historical queries, webhooks for anything that needs an immediate reaction.

What data is typically available

Authentication and security

• API keys are the simplest common authentication method – a secret token included with each request that identifies and authorizes the calling system.
• OAuth-based authentication is used by more sophisticated platforms, offering scoped, revocable access without sharing a long-lived static credential.
• Rate limits restrict how many requests a system can make in a given period, which matters when designing an integration that polls frequently – hitting a rate limit mid-operation can silently drop data if not handled with retry logic.
• Scoped access – limiting an API credential to specific machines, data types, or read-only access – reduces the blast radius if a credential is ever compromised, and is worth configuring deliberately rather than defaulting to full access.

Common integration use cases

• ERP and MES integration. Feeding production counts, downtime, or OEE data into an ERP or MES system to support planning and scheduling decisions, without duplicating manual data entry. Our guide on enhancing MES/ERP with data collection covers this specific use case in more depth.
• Custom internal dashboards. Pulling data into a company-specific tool built for a particular team's reporting needs that a general monitoring dashboard doesn't cover.
• Data warehouses and BI platforms. Feeding historical machine data alongside other business data (sales, quality, cost) for combined analysis, which we cover for two specific tools in our guides on Power BI and Grafana integration.
• Automated workflows. Triggering maintenance tickets, notifications, or other automated processes based on machine events rather than requiring someone to notice and act manually.

Practical steps to build an integration

• Define exactly what data the target system needs. Pulling everything available "just in case" adds unnecessary complexity; start from the specific fields and time granularity the destination actually requires.
• Review API documentation for rate limits and pagination. Historical data queries over large time ranges often need to be paginated rather than requested in a single call.
• Decide between polling and webhooks based on latency needs. If the target system needs near-real-time updates, a webhook-based approach is usually a better fit than frequent polling.
• Handle authentication credentials securely. Store API keys or tokens using the target system's standard secrets management rather than embedding them directly in code or configuration files.
• Build in retry and error handling. Network interruptions or rate limit responses should be handled gracefully rather than silently dropping data.

Common pitfalls

• Polling too aggressively. Requesting data far more often than the target system actually needs it wastes API quota and can trigger rate limiting unnecessarily.
• Assuming raw and computed data are interchangeable. Pulling raw signals when the target system actually needs pre-computed metrics (or vice versa) means redoing calculation logic that the monitoring platform may already handle more reliably.
• Not planning for API changes. Like any software interface, monitoring platform APIs evolve; integrations built without version awareness can break unexpectedly when an endpoint changes.
• Over-broad credential scope. Using a full-access API key for an integration that only needs read access to a handful of machines creates unnecessary risk if that credential is ever exposed.

Frequently asked questions

Do I need to be a developer to use a machine monitoring API?

Building a custom integration generally requires development resources, though the complexity varies – a simple scheduled pull of aggregated metrics is much lighter work than a real-time, bidirectional integration with a complex ERP system.

Should I pull raw data or pre-computed metrics through the API?

It depends on the target system's needs. Pre-computed metrics (like OEE or uptime) save the target system from reimplementing calculation logic and are usually preferable unless the destination genuinely needs to apply its own custom analysis to raw signals.

How often should an integration poll the API for updates?

This depends on how time-sensitive the destination system's use of the data is. Dashboards refreshed a few times an hour are common for non-urgent reporting; anything needing near-real-time response is usually better served by webhooks than frequent polling.

What happens if the API is temporarily unavailable during an integration run?

A well-built integration should retry with backoff and log the failure rather than silently losing the data request. Since most monitoring platforms retain historical data, a temporarily failed pull can usually be retried later without permanent data loss, as long as the integration is designed to handle that case.

Conclusion

An API is what turns a monitoring platform from an isolated dashboard into a data source the rest of the business can actually use – feeding ERP systems, custom BI tools, and automated workflows without manual re-entry. Getting it right comes down to picking the right pattern (REST, webhooks, or both) for the latency the destination actually needs, scoping access deliberately, and building integrations that handle failure gracefully rather than assuming every request succeeds.

Related articles:

• Webhooks for Real-Time Machine Events
• Enhancing MES/ERP with Data Collection
• CNC Data Acquisition: Architecture Basics
• MDCplus Machine Connectivity & Integrations

About MDCplus

Our key features are real-time machine monitoring for swift issue resolution, power consumption tracking to promote sustainability, computerized maintenance management to reduce downtime, and vibration diagnostics for predictive maintenance. MDCplus's solutions are tailored for diverse industries, including aerospace, automotive, precision machining, and heavy industry. By delivering actionable insights and fostering seamless integration, we empower manufacturers to boost Overall Equipment Effectiveness (OEE), reduce operational costs, and achieve sustainable growth along with future planning.