octoplant API: The REST Export API, the octovision Export API and How to Use Them

The octoplant API is really two export interfaces, added a release apart. Release 105 in August 2025 introduced a REST export API on the octoplant side; Spring Release 107 in April 2026 added an octovision Export API aimed at ITSM platforms. Both move data out of AMDT’s tools and into the systems IT and security teams already run. This page explains what each one is for, who typically consumes the data, and how to expose it without opening a path into the control zone.

It is one of three integration pages under OTSSM and Integrations, the overview of how AMDT’s products connect to an IT/OT tool stack.

The two octoplant API releases

	REST export API	octovision Export API	octovision CSV and JSON exports
Arrived	octoplant 105, 8 August 2025	Spring Release 107, 7 April 2026	octovision, announced October 2025
Vendor description	“New REST export API for centralised access and smooth integration with external systems” (Novotek UK)	“Transfer production data to ITSM platforms such as ServiceNow and other enterprise systems” (AMDT)	“Export information via CSV and JSON,” plus an “open API to connect with your SIEM, CMDB, ticketing, or analytics tools” (octoplant.com)
Data behind it	octoplant’s repository: components, versions, jobs (detail gated)	octovision’s inventory, vulnerability and lifecycle data	Same as the octovision Export API
Natural consumer	Reporting, custom tooling, integration middleware	CMDB, ITSM and ticketing	Spreadsheets, audits, SIEM and analytics

Release 105 also standardised the data format of the Asset Inventory exchanged between octoplant servers and hubs, and shipped the first browser-based interface. The release history page covers what else each release changed.

What is not public. Endpoint lists, authentication methods, rate limits, pagination, the exact JSON schema and whether any write operations exist. AMDT’s documentation sits behind the myAMDT login as of October 2026. Anything below that depends on those details is framed as a question to ask, not a fact.

What the two layers expose, in practice

octoplant holds device content. Its repository knows which components exist, which versions of each program and configuration are stored, which jobs ran and what they found. An export from this layer answers “what is running, and when did it last change?”

octovision holds context. Built from octoplant’s data, it adds firmware and software inventory across sites, CVE matches, lifecycle and obsolescence status, and backup and job visibility. Its Summer Release 2026 added criticality classification and a managed versus unmanaged coverage metric (octoplant.com). An export from this layer answers “where is the risk, and are we covered?”

Choosing the wrong layer is a common integration mistake: a SIEM team pulling repository data it cannot interpret, or a CMDB team pulling CVE lists when it wanted firmware versions.

What consumes octoplant API data

Consumer	Data it wants	Layer	Why it pays off
CMDB (ServiceNow or another)	Firmware, software and project versions, components, last backup, lifecycle status	octovision	OT configuration items that describe what each device runs, not just that it exists. See octoplant and ServiceNow
SIEM	Detected changes, job failures, compare results, CVE matches	octoplant and octovision	A logic change becomes an event the SOC can correlate with network alerts
Ticketing	Unapproved changes, failed backups, new CVE matches on critical assets	octovision	Work items with an owner, instead of an e-mail nobody reads
Reporting and KPIs	Backup coverage, job success rate, managed versus unmanaged assets, devices without a recent backup	octovision	Management can see resilience as a number, site by site
Data lake or unified namespace	Change history, versions and lifecycle status over time	Both	Correlate program changes with downtime, quality and OEE data. Our plant data overview covers the architecture

A plant scenario (illustrative). A food manufacturer with six sites wants a monthly board metric: the share of controllers, HMIs and drives with a verified backup less than seven days old. Today a controls lead assembles it by hand from each site. With octovision’s export feeding the reporting tool, the number is produced automatically, and the three sites below target are visible before an incident makes the point for them.

Securing octoplant API access across zones

The octoplant server is one of the most sensitive systems in a plant. It holds every program that runs production, and in many sites it can restore those programs to the devices. An API on that server is therefore a conduit in the IEC 62443 sense, and it deserves the same design as any other path between zones.

The design rules we would apply, in order:

1. Map it as a conduit. Document the API path in the zone and conduit model with source, destination, port and purpose. Our guide to OT network segmentation in a brownfield plant covers how to build that model when the network grew without one.
2. Terminate it in the DMZ. One broker or collector reaches into the OT zone; the CMDB, SIEM and reporting tools talk only to the broker.
3. Use a dedicated, least-privilege account. Read-only, scoped to the data the consumers need, never an engineer’s personal login or an administrator account.
4. Encrypt and allow-list. Encrypted transport, a fixed source address, a fixed port.
5. Log every call on both sides, and send those logs to the SIEM so API use is itself monitored.
6. Rotate credentials and review the account at each octoplant upgrade.

Questions to ask AMDT about the octoplant API

Because the reference documentation is gated, these are the questions we would put to AMDT or a partner before any integration is scoped:

• Authentication: which methods are supported (API keys, tokens, directory accounts), and can a key be limited to read-only access and to specific sites?
• Direction: is data only pulled by the consumer, or can octoplant or octovision push events, such as a detected change, to a webhook or syslog target?
• Schema: which objects and fields are exposed, and is there a published JSON schema for each release?
• Limits: rate limits, page sizes and the load a full export places on the octoplant server during production hours.
• Versioning: how breaking changes are announced, and how long an old API version stays supported after an upgrade.
• Audit: whether every API call is logged on the octoplant side, with the account and the data returned.

Where it gets hard

• Gated documentation. Without the schema you cannot estimate the mapping effort. Ask for the API reference for your release before the purchase order, not after.
• Upgrade coupling. A field renamed in a future release silently breaks a nightly import. Ask AMDT about API versioning and deprecation policy.
• Two APIs, two scopes. The REST export API and the octovision Export API may describe the same device differently. Decide which one feeds which consumer.
• The server becomes a dependency. Once the CMDB and SOC depend on the export, octoplant server availability is an IT service. Agree who supports it out of hours.
• Data volume and frequency. Change history across thousands of devices grows quickly. Agree what each consumer needs (current state, daily deltas or full history) before scheduling exports, or the data lake fills with copies nobody queries.
• Licensing. The per-edition feature split is not public; confirm the APIs are in the edition you own. See editions and licensing.

For the security platform side of the same data, see octoplant and OT security platforms. Back to the AMDT hub.