Connect the Systems. Keep the Data Useful.
Siteplore provides an integration layer for bringing compatible field, operational and enterprise data into a structured monitoring environment — and for making selected Siteplore data available to other systems where a defined integration path exists.
A connected plant can still contain disconnected data.
Sensors, meters, PLCs, building systems, cloud applications and business databases may all contain useful information — but often in different protocols, structures, timestamps and ownership domains. Siteplore helps create defined, controlled paths between those data sources.
Different Protocols
Field devices, APIs and enterprise systems may speak completely different data languages.
Isolated Data Sources
Useful measurements may remain inside individual meters, PLCs, files or applications.
Inconsistent Tag Names
Different systems may use different naming conventions for the same physical asset.
Missing Context
A data point without site, asset, unit and measurement context can be difficult to reuse.
Security Boundaries
OT and IT environments may require carefully controlled network and credential access.
Another Data Silo
A monitoring platform creates limited long-term value if its data cannot be reused where justified.
Siteplore can sit between physical assets, cloud data and operational applications.
Integration architecture is determined by where the data originates, where it needs to go and which system should remain the authoritative source.
Field → Siteplore
Bring compatible sensor, meter and equipment data into cloud monitoring.
Existing System → Siteplore
Reuse selected operational data from existing systems where access is available.
Device → Cloud
Selected edge devices can send data through suitable secure cloud interfaces.
Cloud → Grafana
Historical data can be queried by the configured customer monitoring environment.
Siteplore → External System
Selected data may be exposed to another application through an approved interface.
Application → Workflow
Monitoring data can support downstream automation or reporting workflows where separately defined.
Use the interface appropriate to the system — not one protocol for everything.
Siteplore integration can use different methods across the architecture. The selected approach depends on system capability, data direction, network constraints, update requirements and cybersecurity policy.
REST / HTTPS API
Suitable for structured application-to-application exchange where an authenticated API exists.
MQTT Messaging
Can support lightweight publish / subscribe architectures where messaging is appropriate.
Modbus RTU
Common for industrial field devices, but register map, addressing and serial parameters must be verified.
Modbus TCP
Can be considered where compatible network devices expose the required data.
Database Integration
Selected database sources can be integrated where access, schema and security permit.
File-Based Data
CSV or other structured file sources may support selected historical-data workflows.
Webhooks
Event-driven exchange may be considered where supported by the relevant systems.
Industrial Signal Adapter
Analog, pulse or other field signals may require dedicated acquisition hardware.
Connect systems while preserving ownership, context and security boundaries.
Data Source
Sensor, meter, PLC, application, database or file.
Interface
Protocol, API, adapter or integration path.
Map & Normalize
Preserve asset, unit and measurement meaning.
Siteplore Data Layer
Historical monitoring, dashboard and analytics.
User / Application
Dashboard, API, report or downstream workflow.
Siteplore should not become the next closed data silo.
Where the project requires it, data can enter Siteplore from approved sources and selected information can be made available to approved downstream systems.
Data Into Siteplore
Bring selected operational information into the Siteplore monitoring architecture.
- Field sensor and meter data
- RekaSense edge data
- PowerWatch electrical data
- MachineGuard condition data
- Existing PLC / BMS measurements where permitted
- Compatible databases
- External APIs
- Historical files where appropriate
Data From Siteplore
Make selected monitoring data available to other approved consumers where an interface is defined.
- Custom applications
- Reporting workflows
- External analytics
- Data export
- Integration APIs
- Automation workflows
- Management reporting layer
- Other approved project-specific consumers
Siteplore does not require every existing system to be replaced.
Where technically and organizationally appropriate, Siteplore can complement existing OT and IT systems by consuming selected information without taking over their control or authoritative functions.
PLC / DCS
Selected read-oriented integration may be considered where the system architecture, cybersecurity requirements and data access support it.
BMS
Building and facility data may be integrated where compatible interfaces and permissions are available.
Power Meters
Existing compatible meters can provide electrical and energy measurements to PowerWatch and Siteplore.
IoT Devices
Existing IoT devices may be reusable where data protocols and security can be integrated.
Databases & Applications
Operational or business context may be integrated where suitable APIs, queries or data exchange exist.
Files & Legacy Data
Selected historical information may be imported where its structure, quality and timestamps support the intended analysis.
Moving the data is only half the job.
Data must retain enough context for users and downstream applications to understand what each value represents. Siteplore integration therefore considers naming, timestamps, engineering units, asset identity and source traceability.
Connectivity should not mean unnecessary access.
Industrial integration should follow least-privilege principles, controlled credentials and clearly defined data flows. The exact cybersecurity architecture must align with the customer’s OT and IT requirements.
Least Privilege
A device or application should receive only the permissions required for its intended function.
Separate Credentials
Avoid unnecessary use of one unrestricted credential across multiple devices or customers.
Encrypted Cloud Transport
HTTPS / TLS can be used where supported by the integration architecture.
Read-Oriented OT Access
Monitoring integration should avoid unnecessary write or control access to existing OT systems.
Customer Data Isolation
Customer architecture should preserve appropriate data and credential boundaries.
Credential Lifecycle
Tokens and credentials should be manageable, revocable and rotated where required.
Separate data storage, visualization and customer access responsibilities.
Siteplore can use managed cloud services so the monitoring architecture does not depend on customers maintaining their own visualization servers. Final architecture remains project-specific.
InfluxDB Cloud
Can provide managed historical time-series storage for selected Siteplore measurements.
Grafana Cloud
Can provide dashboards, alerting and analytics for authorized customer monitoring environments.
Siteplore Monitoring
Customer users access their assigned monitoring environment according to the deployed authentication and tenancy model.
Connect data where doing so removes manual work or adds operational context.
Existing Meter Integration
Reuse compatible electrical meter data for cloud energy monitoring.
→ Modbus
→ PowerWatch / Siteplore
PLC Data Context
Use selected process or equipment information as monitoring context where secure access is permitted.
→ Read-Oriented Integration
→ Historical Analytics
Edge-to-Cloud Integration
Send selected field measurements from distributed sites to managed cloud storage.
→ HTTPS / Network
→ Cloud Time-Series
BMS Monitoring Integration
Bring selected building and utility data into cross-domain historical monitoring.
→ Integration
→ Siteplore Dashboard
Production Context
Combine selected production data with energy or utility metrics where appropriate.
+ Utility Data
→ Normalized KPI
Downstream Data Consumer
Provide approved monitoring data to a customer application through a defined interface.
→ API
→ External Application
The integration layer connects Siteplore products with the wider data architecture.
RekaSense
Connect compatible field sensors and remote monitoring points into the Siteplore data path.
Explore RekaSense →PowerWatch
Integrate compatible electrical meters and energy measurements into historical monitoring.
Explore PowerWatch →MachineGuard
Bring selected machine-condition measurements into Siteplore dashboards and analytical workflows.
Explore MachineGuard →API & Integrations defines what can connect. Data Engineering defines how the data becomes usable.
API & Integrations
The connectivity and data-exchange capability within the Siteplore platform.
- Inbound data interfaces
- Outbound integration paths
- Edge-to-cloud integration
- API-based connectivity
- Industrial protocol integration
- Cloud datasource integration
- Customer monitoring access
Data Engineering & Integration
Engineering work required to map, normalize, contextualize and operationalize data from multiple sources.
- Source-system assessment
- Tag and data mapping
- Unit normalization
- Asset contextualization
- Historical architecture
- Data-quality review
- Custom integration implementation
Verify first. Connect second. Validate end-to-end.
Identify
Define the source, required data and intended consumer.
Verify
Confirm protocol, documentation, credentials and access.
Map
Define tags, units, timestamps and asset context.
Integrate
Configure the agreed interface and data path.
Validate
Verify values, timestamps, scaling, visibility and recovery behavior.
Define the interface and the data contract before building the connection.
Exact deliverables depend on the source system, available documentation, required data direction, cybersecurity requirements and commercial scope.
Integration Requirement
Define source, destination, required measurements and update requirements.
Interface Review
Review protocol, API, database or field interface capability.
Data Mapping
Define names, units, scaling, timestamps and asset context.
Credential Architecture
Define suitable least-privilege access where supported.
Integration Configuration
Implement the agreed data-exchange path where included in scope.
End-to-End Verification
Confirm data arrival, timestamp, scaling and destination visibility.
Integration Documentation
Record important system, interface and mapping information where included.
Handover & Support
Explain integration behavior, dependencies and troubleshooting boundaries.
An available protocol does not guarantee an available integration.
Compatibility depends on implementation details, documentation, credentials, network architecture, source-system restrictions and customer cybersecurity policy.
| Capability | Siteplore API & Integrations | Important Boundary |
|---|---|---|
| REST / HTTPS integration | Potentially | Requires compatible API and authentication |
| MQTT integration | Where designed | Broker, security and topic architecture required |
| Modbus RTU | Commonly applicable | Register map and serial parameters required |
| Modbus TCP | Potentially | Network and device access must be permitted |
| PLC / BMS data | Potentially | Depends on available interface and OT policy |
| Database integration | Potentially | Schema, query and credential access required |
| External application API | Project-specific | Interface contract must be defined |
| Universal device compatibility | No | Every device and protocol implementation must be verified |
| Direct 4–20 mA input | Not assumed | Requires suitable analog interface hardware |
| Write control to PLC | Not by default | Control access requires separate engineering and approval |
| Safety-system integration | Not assumed | Safety-system requirements need specialist engineering |
| Guaranteed network availability | No | Depends on customer and carrier network architecture |
| Guaranteed third-party API continuity | No | External providers can change APIs and authentication |
| Automatic cybersecurity compliance | No | Security requirements must be assessed per project |
Before asking “which API?”, define which data should move — and why.
Site Assessment
For organizations that need to understand existing systems before defining the integration architecture.
- Source-system review
- Protocol and interface assessment
- Data-flow definition
- OT / IT access discussion
- Recommended integration architecture
90-Day Paid Pilot
Validate one clearly defined data path before connecting a larger number of systems.
- Selected source system
- Defined data set
- Integration configuration
- Historical dashboard / verification
- Pilot findings & scale recommendation
Integration Project
For organizations that need multiple data sources or applications integrated into the Siteplore architecture.
- Multiple source systems
- Data mapping and normalization
- Cloud integration architecture
- Customer monitoring environment
- Documentation & handover scope
API & Integrations FAQ
What is Siteplore API & Integrations?
It is the Siteplore platform capability for connecting compatible field, operational, cloud and external application data through defined interfaces.
Does Siteplore provide an API?
Project-specific API access can be designed where required. The exact interface, authentication, data model and supported operations must be defined for the deployment.
Can Siteplore use REST APIs?
Yes, where the source or destination system provides a compatible API and the necessary authentication and network access are available.
Can Siteplore use MQTT?
MQTT can be considered where publish / subscribe messaging is appropriate. Broker architecture, authentication, topic structure and device behavior must be separately defined.
Does RekaSense use MQTT?
MQTT may be used in architectures that benefit from messaging, but it should not be assumed as the only transport. Direct secure HTTPS to the configured cloud data layer may also be appropriate depending on the deployment.
Can Siteplore integrate Modbus sensors?
Compatible Modbus RTU or Modbus TCP devices can potentially be integrated. Register maps, addressing, communication parameters, data types and scaling must be verified.
Does RS485 mean a sensor is automatically compatible?
No. RS485 defines the electrical communication layer. The protocol, register map, baud rate, parity, slave ID, power and wiring must also be compatible.
Can existing PLC data be used?
Potentially yes, where the PLC or surrounding architecture exposes an approved interface and the customer’s OT cybersecurity policy permits access.
Can Siteplore write commands to a PLC?
Siteplore should not be assumed to provide control access. Write or command functions require separate controls engineering, permissions, interlocks, cybersecurity review and validation.
Can Siteplore integrate with a BMS?
Potentially yes where the BMS exposes suitable data through an accessible and approved interface.
Can existing databases be integrated?
Potentially yes. Database integration depends on database technology, schema, credentials, connectivity, query requirements and security restrictions.
Can Siteplore import historical CSV data?
Historical file data can potentially be imported where timestamps, units, identifiers and data quality support the intended analysis.
Can another application retrieve Siteplore data?
Yes, where an outbound interface is included in the project architecture. The data scope, authentication, request model and rate requirements must be defined.
Can Siteplore integrate with ERP or CMMS systems?
Potentially, where the relevant system provides an accessible API or another supported integration mechanism. A specific ERP or CMMS integration should not be assumed until technical compatibility is verified.
Does Siteplore replace SCADA or DCS?
No. Siteplore is positioned as a monitoring, historical-data and analytics layer. SCADA, PLC and DCS systems remain responsible for their control and plant-operational functions.
Can Siteplore send data directly to InfluxDB Cloud?
A secure direct edge-to-cloud data path can be considered where supported by the selected device, cloud API and cybersecurity architecture.
What is Grafana Cloud’s role?
Grafana Cloud can provide the visualization, alerting and analytics layer for Siteplore customer monitoring. It is not itself the complete Siteplore solution.
How are customer credentials separated?
Customer architectures should use appropriate identity, token and data-access boundaries. The exact model depends on the deployed cloud services and customer security requirements.
Can one API token be used for all customer devices?
Using one unrestricted master credential across multiple customers is not the preferred architecture. Least-privilege, customer- or device-scoped credentials should be used where the selected platform supports them.
Does API integration guarantee real-time data?
No. End-to-end latency depends on source-system update rate, network, polling or messaging method, ingestion, processing and consumer behavior.
Can Siteplore integrate with any system?
No universal compatibility should be assumed. Rekacipta first needs to review the system’s interface, documentation, credentials, data model, cybersecurity requirements and project constraints.
How should an integration project start?
Start by defining the source system, the exact data required, the destination, the expected update frequency and the operational reason for moving that data. Then verify which interface can meet the requirement safely.
Do not integrate systems simply because an API exists. Connect the data that improves a decision.
Rekacipta can help identify the required data flow, verify available interfaces, map operational data, design the edge-to-cloud architecture and integrate selected systems into a Siteplore monitoring environment without unnecessarily replacing the systems that already work.