Your sensors see a lot. A flow meter reads consumption every minute. A door contact knows when a freezer was opened. A motor reports vibration that drifts out of range before it fails. All of that is real, and most of it never reaches the systems your business actually runs on. The billing happens in an ERP. The customer history lives in a CRM. The service ticket gets opened by a person who heard about the problem hours after the device already knew.
The work is closing that loop. When a sensor sees something, the business should act on it: a usage reading becomes an invoice line, a fault becomes a ticket, an asset reading updates the record your account team looks at. This post covers the patterns for connecting device data to ERP and CRM systems, the parts that bite you if you skip them, and how to do it on TagoIO with the REST API, Analysis scripts, and webhook actions.
Why connect device data to business systems
Device data on its own is monitoring. Connected to a business system, it becomes action.
A few examples make the value concrete:
- A utility meter reports cumulative usage. Pushed into the ERP on a billing cycle, it turns into an accurate invoice with no manual reads.
- A machine throws a fault code. Pushed into the CRM or a field-service module, it opens a ticket and assigns a technician before the customer calls.
- An asset’s runtime hours cross a threshold. The asset record updates, and a maintenance contract triggers on schedule.
- A high-value installation goes quiet. The sales owner who manages that account gets a notification instead of finding out at the next quarterly review.
In each case the device already knew. The gap was getting that signal into the system where someone could do something about it.
The integration patterns
There are a handful of patterns you will reach for, and most real integrations combine two or three of them.
Webhooks. The device platform pushes data to a URL when something happens. This is the right default for events: a fault, a threshold crossing, a state change. The receiving system gets the payload the moment it matters, and you are not polling.
REST APIs. The pull side of the same coin. Your ERP or CRM, or a script in the middle, calls an endpoint to read device data on demand or on a schedule. Good for batch sync, like pulling a day of meter readings at midnight, and for any system that prefers to ask rather than be told.
Middleware and iPaaS. Tools like n8n, Make, or a workflow engine sit between the platform and the business system. They handle retries, transformation, and the awkward mapping where one system’s field names do not match the other’s. When you have more than one target system or the logic gets branchy, middleware keeps it out of both ends.
Event-driven triggers. Logic that runs when a condition is met rather than on a clock. A reading arrives, a rule evaluates it, and an action fires only if the condition holds. This keeps you from hammering the CRM with every reading when you only care about the ones that cross a line.
Data mapping and sync considerations
This is where integrations quietly break. The transport is the easy part. Keeping two systems agreeing on the same facts is the hard part.
Identifiers. Every device needs a stable mapping to its counterpart in the business system: a device to an asset record, a meter to a customer account, a machine to a service contract. Decide where that mapping lives and keep it authoritative. Tag the device with the ERP asset ID, or keep a lookup table the integration reads. What you do not want is matching on names that someone will rename next quarter.
Frequency. Match the sync rate to the use case. Billing reads can run daily. Fault tickets need to fire in seconds. Asset-runtime updates might be hourly. Sending everything in real time is wasteful and will rate-limit you against the target system. Sending too slowly means stale records.
Idempotency. Networks retry. If a webhook delivery times out and fires again, you do not want two invoices or two duplicate tickets. Give each event a unique key the receiving system can dedupe on, and design the target operation so that running it twice with the same key changes nothing the second time.
Auth and security
You are connecting an operational platform to systems that hold money and customer data, so the credentials matter.
Use scoped tokens, not account-wide keys. The token an integration uses to push a meter reading into the ERP should be able to do that and nothing else. If it leaks, the blast radius is one operation, not your whole account.
Apply least privilege on both ends. The TagoIO side reads only the devices the integration needs. The ERP or CRM side accepts writes only to the objects in scope. Rotate keys on a schedule and store them where they are not sitting in plain text in a script. TagoIO is ISO 27001 certified and GDPR-aligned, but that posture only holds if the credentials you issue follow the same discipline.
How TagoIO connects to ERP and CRM systems
TagoIO does not ship a one-click SAP or Salesforce button, and you should be skeptical of any platform that claims a prebuilt connector for every enterprise system. What TagoIO gives you is the building blocks to wire the integration yourself, with the logic living where you can see and change it.
The REST API. Every device, variable, and piece of stored data is reachable over the API. An external system, or an iPaaS like n8n, can pull readings on a schedule and push them into the destination. Your NetSuite integration can call the TagoIO API nightly, read the day’s consumption per meter, and post invoice lines.
Analysis scripts. These are serverless scripts that run inside TagoIO, in Node.js or Python. This is usually where the real work happens. An Analysis can trigger on incoming data, evaluate a condition, transform the payload into the shape the target system wants, and call the ERP or CRM API directly. Connecting to HubSpot or Salesforce becomes a matter of an HTTP call from your script to their API with a scoped token, plus the mapping logic in between. Because it runs in the platform, you are not standing up a server to host it.
Webhook actions. TagoIO Actions can fire a webhook when a condition is met. A fault variable crosses a threshold, the Action posts to your service-desk endpoint, and a ticket opens. For event-driven work where you want a push the moment something happens, this is the shortest path. Pair it with an Analysis when the payload needs reshaping before it reaches SAP or your CRM.
A common shape for a real integration: an Action detects the event, an Analysis script reshapes and enriches the data and handles idempotency, and the script calls the enterprise system’s REST API with a scoped token. That covers the fault-to-ticket case, the usage-to-invoice case, and the asset-update case with the same three pieces in different arrangements.
Where to start
Pick one loop that is currently manual and close it. Usage-to-invoice and fault-to-ticket are the two that pay back fastest because they remove a person from a repetitive path. Map the identifiers first, decide the sync frequency, build the Analysis that does the transform, and test idempotency by deliberately firing the same event twice. Once one loop works end to end, the rest follow the same pattern.
