Do you need a vendor API to connect a terminal's tank gauging system?

No. Most terminals can be connected through one of four routes that require no vendor API: a scheduled report the system already emails, a structured export the system already produces, a read-only database user where the vendor supports it, or a direct protocol read over OPC UA or Modbus. The scheduled report route requires nothing from the vendor at all.

Does connecting an operational layer mean opening the terminal network to inbound traffic?

It should not, and this is the property to insist on. In an outbound-only architecture an agent inside the terminal network initiates every connection outward and the platform never connects into the site. No inbound firewall rule is opened, which is normally the condition for passing an OT security review.

What happens to terminal data during a network outage?

A store-and-forward agent queues readings locally while the link is down and transmits them when connectivity returns, so an outage produces delayed data rather than a permanent gap. This matters because gaps in an operational record are the failures that surface later during an audit.

Guide · Architecture

Connecting systems without an integration project

The objection that kills terminal software is not price. It is risk to operational technology that already works, and most of that risk comes from how the connection is made, not from what it connects to.

Start from what the systems already produce

Direct answer

Most terminals can be connected without a vendor API, a migration, or a change to any existing system. There are four routes in, and they descend in order of how much they ask of you: a scheduled report the system already emails, a structured export it already produces, a read-only database user where the vendor supports one, and a direct protocol read over OPC UA or Modbus. The first route asks the vendor for nothing whatsoever.

The instinct in most integration conversations is to start at the deepest route and work back. That is backwards. Start at the shallowest route that answers the question, because every step deeper adds a vendor dependency, an IT approval, and a way for the project to stall for reasons unrelated to whether the idea was any good.

The four routes in

Route	What it needs	Freshness	Best for
Scheduled report	Nothing. The system already emails it to someone.	Daily, typically	Tank levels, daily stock positions. The fastest possible start.
Structured export	Someone runs an export, or schedules one. CSV, XML, JSON.	On demand or scheduled	Maintenance history, HSSE registers, contract workbooks, backfilling years of history.
Read-only database user	Vendor support for it, plus an IT change. No writes, ever.	Near real time	CMMS platforms that ship a selection-to-database facility. Deeper detail than an export.
Direct protocol read	OPC UA endpoint or Modbus register map.	Continuous	Gauging and automation systems where continuous readings matter.

The route people skip. Almost every terminal already emails a daily tank report to a handful of internal recipients. That report is a working data feed nobody thinks of as one. Reading it requires no vendor, no IT ticket and no approval beyond adding a recipient, and it is frequently enough to answer the first real question, which is the one that decides whether anything deeper is worth doing.

The property that decides your OT security review

Ask one question of any vendor proposing to connect to your plant: which direction does the connection go?

In an outbound-only architecture, a small agent runs inside the terminal network, reads from the systems it is pointed at, and pushes outward to the platform. The platform holds no route in. There is no inbound firewall rule, no exposed endpoint on the plant network, and no listening service for anyone to reach.

This is not a marketing distinction. It is usually the difference between a security review that concludes in a fortnight and one that never concludes at all, because the reviewer's core question, "what new way into our network does this create," has the answer "none."

Outbound only

The agent initiates every connection. Nothing inbound is opened, and the platform cannot reach the site.

Read only

Nothing writes back to a source system. The layer cannot alter a work order, a tank reading or a setpoint.

Store and forward

Readings queue locally through an outage and transmit on recovery, so a dropped link delays data instead of losing it.

Credentials encrypted at rest

Integration tokens and database credentials are encrypted where they are stored, not held in a configuration file in plain text.

What the connection has to do beyond moving bytes

Moving data is the easy half. The half that determines whether the result is trustworthy:

Map vendor terms to one model. Gauging vendors disagree about what to call a level, a temperature, an observed volume and a net standard volume. Until those become one vocabulary, cross-site comparison is guesswork with a confident interface.
Preserve the source, not just the result. Every derived figure keeps a path back to the raw record it came from. Without this you have a dashboard; with it you have evidence.
Reconcile against what the tank actually did. Movements reported by a commercial system and volumes implied by gauging will disagree. Surfacing the discrepancy is the value; silently picking a winner destroys it.
Handle the messy history. A decade of real records contains format changes, retired conventions and entries from people who left years ago. This is the normal starting condition, not a precondition to clean up first.
Report the connection's own health. A feed that quietly stops is worse than no feed, because the record looks complete. Liveness has to be visible on its own.

A realistic sequence

Roughly how a connection programme should be ordered, shallowest first, so that each step is justified by what the previous one showed.

Add a recipient to the daily report. Zero vendor involvement. Produces a live feed within days.
Export the history once. Maintenance, HSSE and contracts, as a one-off. This is what makes patterns visible, and it needs no ongoing integration at all.
Answer one real question against the joined result. Before anything deeper is discussed. If this step does not produce something the separate systems could not, stop: the deeper routes will not rescue it.
Then, if warranted, go deeper on one system. A read-only database user or a protocol read, for the single system where freshness genuinely changes the answer.

Why this order matters commercially. Sequenced this way, the first two steps carry almost no risk and no IT dependency, and the decision to go deeper is made against evidence from your own data. Sequenced the other way, full integration scoped up front, the same programme needs a security review, a vendor conversation and a budget approval before anyone has seen it answer a single question.

Common questions

Our gauging system is old and the vendor is unhelpful. Does that rule us out?

Usually the opposite. Older gauging kit tends to speak Modbus, which needs a register map rather than vendor cooperation, and it almost always drives a daily report that can be read with no vendor involvement at all. The harder cases are newer closed systems with a proprietary interface and a licence gate.

Can you connect our CMMS without buying an additional vendor module?

Through export, yes: every CMMS worth the name exports work orders. A read-only database connection is deeper and some platforms provide a facility for it, occasionally as a licensed module. The honest sequence is to start with exports, prove the value, and only then decide whether the deeper route is worth a licence conversation.

What happens when a vendor changes their export format?

It breaks, which is why the connection has to report its own health rather than fail quietly. A parse failure should be visible immediately as a failure, not as a feed that has stopped producing rows while the record continues to look intact.

How much of our IT team's time does this take?

For the first two routes, close to none: adding an email recipient and running an export are operations tasks, not IT projects. The read-only database user and the protocol read do require IT involvement, which is precisely why they are sequenced after you have seen the value rather than before.

Start with the report you already send

The Shadow Pilot works from historical exports only: no connector, no agent, nothing for IT to approve. Thirty days, and you keep the findings.

Apply for a Shadow Pilot Read the security model