Reference · built on requestConnectorPLC, SCADA & MES

Ignition

Gateway configuration resources, deployment modes, and sync state from Ignition 8.3 through its token-authenticated HTTP API.

Request accessPricing ↗

About

Ignition is Inductive Automation's SCADA, HMI, and MES platform, run as a Gateway with installed modules. From version 8.3 the Gateway publishes an OpenAPI specification of every HTTP route its modules document, browsable at /openapi and downloadable at /openapi.json. Configuration elements are exposed as resources under /data/api/v1/resources, where a client can list, read, create, update, and delete them by module and type, attach data files, run sync operations, and read deployment modes. Requests authenticate with an API Key sent in the X-Ignition-API-Token header.

An operator on Fibric reads resource definitions and their changes, then proposes a create, update, or delete for your approval. Mutative calls land in the Gateway audit log with the key that made them, and each carries a receipt.

This is a reference listing. It documents what Fibric would read from Ignition and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • The Gateway's route catalog from /openapi.json, listing each documented endpoint, its parameters, authentication, and response schema
  • Configuration resources by module and type through GET /data/api/v1/resources/list/<moduleId>/<typeId>
  • Data files attached to configuration resources, retrievable through the resource routes
  • Deployment modes through /data/api/v1/modes, together with the collections a mode inherits from (system, external, and user-defined)
  • Configuration sync state through /data/api/v1/sync

Proposed actions

  • Target capability: propose a new configuration resource through POST /data/api/v1/resources/<moduleId>/<typeId>
  • Target capability: propose an update to an existing resource, with the current definition shown beside the change
  • Target capability: propose deleting a named resource through DELETE /data/api/v1/resources/<moduleId>/<typeId>/<name>/<signature>
  • Target capability: propose a configuration sync operation through /data/api/v1/sync

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Annotate every gateway change

    Read resource definitions on a schedule, diff them against the last snapshot, and post an annotation naming what changed and which key changed it.

    With Change Annotation

  • Keep integrations from breaking quietly

    Re-read the /openapi.json catalog and the resources an integration depends on, and raise a notice when a route or resource disappears after a module update.

    With Integration Health

  • Prove a gateway's configuration is current

    Compare sync state and resource signatures across gateways sharing a deployment mode, and flag the one whose resources lag the source.

    With Data Freshness

Requirements

  • An Ignition 8.3 Gateway, since resource routes and the /openapi specification arrived in that version
  • A user with write permissions on Security > General Settings to create the API Key; the key is shown once at creation
  • HTTPS to the Gateway, because "Require secure connections for API Keys" is on by default
  • Auditing enabled at the Gateway level so mutative requests are recorded with user, IP address, and key
Authentication
An Ignition API Key of type Basic Token, created under Platform > Security > API Keys, sent in the X-Ignition-API-Token header over a secure connection, and bounded by the security levels assigned to the key.

Limits

  • Only routes that installed modules explicitly document appear in the API; internal and session-dependent routes are excluded
  • A key grants full access to the Gateway's HTTP API routes, including changes to configuration, tags, and projects, bounded only by its security levels
  • GET requests are not written to the audit log; only POST, PUT, and DELETE are recorded
  • Inductive Automation cautions that API use can lose configuration, tags, or projects and degrade Gateway performance

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Ignition ↗

Questions and answers

How do I authenticate against the Ignition Gateway API?
Create an API Key under Platform > Security > API Keys (Basic Token is the only type), copy it at creation because it cannot be shown again, and send it in the X-Ignition-API-Token header. The Gateway stores a hash, checks the key's security levels, and by default requires a secure connection.
Where is the list of available endpoints?
On the Gateway itself: http[s]://<gateway-host>:<port>/openapi is the interactive page and /openapi.json the machine-readable spec. Both are generated from the current state of the Gateway and its installed modules, so the list changes as modules are added or removed.
Are API changes audited?
Mutative requests (POST, PUT, DELETE) are recorded in the Gateway audit log with the user, IP address, and API key, once auditing is enabled at the Gateway level. GET requests are not recorded.
Ask about Ignition

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Ignition through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy