How to Connect IoT Device Data to Your ERP: Integration Patterns for Supply Chain

Your sensors are working. Data is streaming into your IoT platform: temperature readings every 30 seconds from reefer trucks, GPS pings from pallets, humidity levels from warehouse zones. And your ERP has no idea any of it exists. Purchase orders close without acknowledging a four-hour temperature excursion. Inventory counts don’t reflect that a shipment arrived 40 minutes ago. A maintenance-critical vibration spike goes unnoticed until something breaks.

The gap between “data is flowing” and “the ERP acts on it” is where most IoT-to-ERP integration projects stall. IoT platforms speak MQTT, time-series databases, and high-frequency telemetry. ERPs speak business objects, batch transactions, and relational records. Bridging that semantic divide reliably, at scale, without creating a maintenance nightmare, is the actual engineering challenge.

This article covers the architecture between your IoT platform and your ERP. Not sensor selection. Not gateway setup. Not ERP configuration. The pipe in the middle: protocols, transformation, middleware, and delivery patterns for SAP, NetSuite, and adjacent supply chain platforms like Palantir Foundry.

Why IoT-to-ERP Integration Is Harder Than a REST Call

The instinct is to grab the ERP’s API docs and start POSTing sensor data. Here’s why that impulse breaks down fast.

Impedance mismatch. A temperature sensor on a reefer truck emits a reading every 30 seconds. That’s 2,880 data points per sensor per day. SAP doesn’t want 2,880 records. It wants one quality hold event on a batch when a threshold was breached for longer than 15 minutes. The gap between “raw signal” and “business-meaningful event” is where the real work lives.

Schema mismatch. IoT data is time-series: timestamp, device ID, value. ERP data is relational and object-oriented: purchase orders with line items, inventory records with lot numbers, ASNs with carrier references. There’s no natural mapping between them.

Volume mismatch. Even a modest deployment of 200 sensors generating data every 30 seconds produces 576,000 readings per day. Most ERP APIs have rate limits (NetSuite’s concurrency governance allows roughly 10–25 concurrent requests depending on your license tier). Pushing raw telemetry into an ERP will get you throttled, or worse, destabilize the system.

And then there’s compliance. If you’re in food, pharma, or medical devices, FDA and FSMA regulations require your data pipeline to be auditable. You can’t just fire-and-forget sensor data into an ERP. You need to prove the chain of custody from sensor reading to business record.

The concept I’ll return to throughout: you need a semantic bridge, a transformation layer where raw IoT telemetry becomes ERP-meaningful business objects.

Three Integration Patterns for IoT-to-ERP Connectivity

There are three dominant approaches. Each has legitimate use cases. The right one depends on your ERP’s constraints, your data volume, and how many downstream systems need the data.

Pattern A: Direct API Integration

How it works: Your IoT platform pushes data to custom code (a Lambda function, a Cloud Function, a containerized service) that transforms it and writes directly to the ERP’s API.

Representative stack: AWS IoT Core → Lambda → SAP OData API or NetSuite RESTlet.

When to use it: Fewer than 50 devices, a single ERP target, straightforward transformation logic, or a proof of concept you need running in two weeks.

Trade-offs: This is the fastest path to production and the fastest path to regret at scale. You own the retry logic, error handling, rate-limit management, and monitoring. You’re tightly coupled to the ERP’s API surface. When SAP deprecates an OData endpoint or NetSuite changes its token refresh behavior, your pipeline breaks. There’s no built-in orchestration if you need to write to multiple systems.

When it breaks down: Multiple ERP targets, complex transformation requirements, high device counts, or any scenario where you need guaranteed delivery with audit trails.

Pattern B: Middleware / iPaaS Broker

How it works: Your IoT platform pushes data to an integration platform (MuleSoft, Boomi, SAP Integration Suite, Celigo, Workato) that handles transformation, routing, retry logic, and delivery to the ERP.

Representative stack: Azure IoT Hub → MuleSoft Anypoint → SAP S/4HANA + NetSuite (simultaneously).

When to use it: Enterprise environments with multiple target systems, teams that don’t want to build and maintain custom integration code, or organizations already invested in an iPaaS platform.

These platforms give you transformation mapping (often visual), built-in retry with dead-letter handling, monitoring dashboards, and pre-built connectors for major ERPs. For SAP shops, SAP BTP Integration Suite is the natural choice because it understands SAP’s data model natively. For NetSuite environments, Celigo is purpose-built and handles NetSuite’s concurrency governance gracefully.

Trade-offs: Licensing costs can be significant ($50K–$200K+ annually for enterprise iPaaS). You’re accepting platform lock-in. And there’s latency: most iPaaS platforms add 500ms–2s per message hop, which matters if you’re targeting near-real-time alerting.

Pattern C: Event-Driven / Streaming Architecture

How it works: Your IoT platform publishes to a message broker (Kafka, AWS Kinesis, Azure Event Hubs). A stream processor (Apache Flink, ksqlDB, a custom consumer) applies the semantic bridge logic — windowed aggregations, threshold detection, event generation — and pushes curated events to the ERP and any other consumers.

Representative stack: MQTT broker → Kafka → Flink → SAP OData API + Palantir Foundry + alerting service.

When to use it: High device counts (hundreds to thousands), real-time alerting requirements, multiple downstream consumers beyond the ERP, or scenarios where supply chain analytics platforms like Palantir Foundry or Kinaxis need the same data.

This is the pattern that truly decouples producers from consumers. The ERP is just one subscriber. Your analytics platform is another. Your alerting service is a third. The semantic bridge lives in the stream processor, and each consumer gets data shaped for its needs.

Trade-offs: This is the most complex architecture to build and operate. You need stream processing expertise. You need to manage broker infrastructure (or pay for managed services). For a 30-device deployment feeding a single ERP, this is overkill.

PATTERN A: Direct API
┌──────────┐    ┌──────────┐    ┌──────────┐
│  Sensor  │───▶│  Custom  │───▶│   ERP    │
│ Platform │    │  Code    │    │  (API)   │
└──────────┘    └──────────┘    └──────────┘

PATTERN B: Middleware / iPaaS
┌──────────┐    ┌──────────┐    ┌──────────┐
│  Sensor  │───▶│  iPaaS   │───▶│   ERP    │
│ Platform │    │(MuleSoft,│    │  (API)   │
└──────────┘    │ Boomi,   │    └──────────┘
                │ Celigo)  │
                └──────────┘

PATTERN C: Event-Driven / Streaming
┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  Sensor  │───▶│  Message  │───▶│  Stream  │──┬▶│   ERP    │
│ Platform │    │  Broker   │    │ Processor│  │ │  (API)   │
└──────────┘    │(Kafka,   │    │(Flink,   │  │ └──────────┘
                │ Kinesis) │    │ ksqlDB)  │  │ ┌──────────┐
                └──────────┘    └──────────┘  └▶│ Analytics │
                                                │(Palantir,│
                                                │Databricks)│
                                                └──────────┘

The Transformation Layer: Where Projects Succeed or Fail

Regardless of which pattern you choose, the semantic bridge is the intellectual core of the project. This is where supply chain IoT data becomes ERP-actionable. Get this wrong and you’re writing garbage into your system of record.

Here are concrete transformation examples:

The pattern determines where this logic lives. In Pattern A, it’s in your Lambda function or custom service. In Pattern B, it’s in the iPaaS mapping/transformation layer. In Pattern C, it’s in the stream processor.

Two non-negotiable requirements regardless of location:

Idempotency. ERP writes must be safe to retry. If your pipeline delivers a quality hold event twice (because of a network retry, a reprocessed Kafka offset, or an iPaaS retry), the ERP shouldn’t create two quality holds. Use idempotency keys. Most ERP APIs support external reference IDs for deduplication.

Auditability. For FDA/FSMA compliance scenarios, you need to trace any ERP business object back to the raw sensor readings that triggered it. Log every transformation decision. Store the raw data alongside the derived events.

How to Connect IoT Data to SAP S/4HANA and ECC

SAP has the most mature IoT-to-ERP integration story, but it comes with layers.

SAP BTP (Business Technology Platform) is the recommended integration hub. It sits between your IoT pipeline and S/4HANA, offering the SAP Integration Suite for managed connectivity, pre-built adapters, and data mapping tools that understand SAP’s object model natively.

For S/4HANA: Use OData APIs. SAP publishes a comprehensive API catalog (api.sap.com) with endpoints for quality management, inventory, maintenance, and logistics. You can create quality notifications, goods receipts, and maintenance orders via standard OData services.

For older ECC systems: You’re looking at BAPIs and RFCs, typically accessed through SAP’s JCo connector or via the Integration Suite’s RFC adapter. This is less RESTful and more brittle, but it’s often the only option for brownfield deployments.

Rate limits matter. SAP’s OData APIs on S/4HANA Cloud have throttling. Batch your writes where possible. SAP OData supports $batch requests that bundle multiple operations into a single HTTP call. For high-volume scenarios, the SAP Integration Suite can buffer and batch on your behalf.

SAP also offers Digital Supply Chain solutions that accept IoT data more natively, but they require additional BTP licensing and are a heavier commitment.

IoT NetSuite Integration Patterns

NetSuite’s integration surface is more constrained than SAP’s, which actually simplifies some decisions.

RESTlets are your best friend for IoT-shaped payloads. They’re custom endpoints you deploy as SuiteScript, meaning you control the request/response schema. You can design a RESTlet that accepts exactly the JSON structure your transformation layer produces, with no awkward mapping to a generic SOAP envelope.

SuiteTalk (SOAP API) and the newer REST API are alternatives for standard record operations (creating inventory adjustments, updating item records, posting work orders). The REST API is more modern but has narrower record coverage than SuiteTalk.

Concurrency governance is the critical constraint. NetSuite limits concurrent API requests based on your license tier. A burst of sensor-triggered events can exhaust your concurrency slots and block other integrations, including other business-critical processes. Implement queuing in your transformation layer: buffer events and drip-feed them to NetSuite at a controlled rate.

Celigo is the most common iPaaS for NetSuite-centric architectures, with purpose-built NetSuite connectors that handle concurrency management, field mapping, and error routing. Workato is another strong option, particularly if you’re orchestrating across multiple cloud applications beyond NetSuite.

Brief mentions for other ERPs: Microsoft Dynamics 365 benefits from native Azure ecosystem integration (Azure IoT Hub → Dataverse → D365). Oracle Cloud ERP can ingest through Oracle IoT Cloud or standard REST APIs. Infor uses its ION messaging backbone for event-driven integration.

The Analytical Layer: Palantir Foundry and What Comes Next

A growing architecture pattern inserts an analytical/operational platform between the IoT pipeline and the ERP. Instead of pushing every derived event directly into the ERP, you land supply chain IoT data in a platform designed for analysis and operational decision-making, then selectively push curated records to the ERP.

Palantir Foundry is the most visible example in supply chain. It ingests IoT streams, applies ontology mapping (its term for the semantic bridge), enables operational teams to explore and act on data, and can push decisions to the ERP via API. You get the analytical flexibility of a data platform without overloading your ERP with data it wasn’t designed to store.

Kinaxis (supply chain planning), Databricks (lakehouse analytics), and Snowflake serve similar intermediate roles for different use cases.

This pattern makes sense when multiple teams need IoT-derived insights, not just the ERP workflow owners. Your quality team wants dashboards. Your logistics team wants real-time tracking. Your planning team wants predictive models. The ERP stays a system of record, not a system of analysis.

Choosing Your Pattern and Building the Pipeline

                    START
                      │
         ┌────────────▼─────────────┐
         │  How many sensor devices  │
         │  feeding the ERP?         │
         └────────────┬─────────────┘
              ┌───────┴───────┐
          < 50 devices    50+ devices
              │               │
     ┌────────▼────────┐  ┌──▼──────────────┐
     │ Need multi-system│  │ Need real-time   │
     │ orchestration?   │  │ + multi-consumer?│
     └───────┬─────────┘  └──┬──────────────┘
         ┌───┴───┐       ┌───┴───┐
         No     Yes      No     Yes
         │       │       │       │
    ┌────▼──┐ ┌─▼────┐ ┌▼────┐ ┌▼────────┐
    │PATTERN│ │PATTERN│ │PAT. │ │PATTERN C │
    │   A   │ │   B   │ │ B   │ │Streaming │
    └───────┘ └──────┘ └─────┘ └──────────┘

Here’s how to start, regardless of which pattern you choose:

Step 1: Start from the ERP side. Map the exact business objects you need to create or update: quality notifications, inventory adjustments, ASN confirmations, work orders. Work backward from there. The ERP’s data model, rate limits, and API capabilities should dictate your architecture, not your IoT platform’s features.

Step 2: Quantify your data volume and latency requirements. Fifty sensors at 30-second intervals feeding a single ERP? Pattern A is fine. Five hundred sensors feeding SAP, NetSuite, and a Palantir Foundry instance? You need Pattern C.

Step 3: Prototype with Pattern A. Even if you know you’ll need Pattern B or C in production, validate your ERP writes with a simple direct integration first. Confirm that your business object mapping works, that your idempotency logic holds, and that the ERP behaves as documented. This takes days, not weeks, and saves you from discovering ERP-side surprises deep into a complex streaming build.

Step 4: Invest disproportionately in the transformation layer. This is your biggest maintenance surface and your core differentiator. The logic that decides “these 47 temperature readings constitute an excursion event that warrants a quality hold on lot #X” is domain-specific, evolves with your business rules, and needs to be testable in isolation.

Step 5: Build observability from day one. Dead-letter queues for failed ERP writes. Pipeline lag dashboards. Alerts on transformation failures. If a sensor-to-ERP pipeline fails silently, you don’t get a second chance. That missed temperature excursion becomes a compliance violation or a product recall.

The IoT-to-ERP integration pattern you choose matters less than how well you build the semantic bridge in the middle. Get the transformation right, respect the ERP’s constraints, and instrument everything. The sensors are already talking. Make sure the ERP is listening.

Hubble Network connects Bluetooth IoT devices directly from the source—anywhere on Earth—without gateways or complex infrastructure. See how it works →