The Flow Server REST API
The web client's own API, used from outside — the controller surface, authentication, and the rules for building on it.
Everything the Infohub web client shows, it fetches over HTTP from Flow Server — which means there is a real REST surface, and integrators already use it (dashboards in Ignition, chart data pulled into other tools). It has never been documented as an API. This article maps the surface and states the rules for depending on it.
The surface, by controller#
Flow Server's API groups into controller families; the ones relevant to external readers:
| Family | Serves |
|---|---|
| Data | The values behind the client: chart data, measure values, event scheme data, form data, time-period values |
| Model | The model shape: folders, metrics, measures, event schemes |
| Definition | Chart/dashboard/form/palette/theme definitions — what a chart is, as opposed to its data |
| DataSources | Data source browse/preview surfaces |
| Export | Chart export — GET api/export/Charts/{id}/{exportType} returns the rendered chart (Jpeg/Png/Pdf via headless render; CSV where the chart type supports data export) |
| Index/Search | The client's navigation and search |
| Template | Chart template surfaces |
| Config / System / Token | Administrative and session plumbing — not integration surfaces |
The practical reading: Data + Export are the integration-friendly read endpoints (chart-shaped data and finished renders), Model answers "what exists", and Definition is for tooling that reasons about configuration.
Discovering exact routes#
The authoritative route list is the running server's own — discover rather than guess:
- Open the web client with browser dev-tools on the Network tab; every pane you open shows its exact request, parameters included. This is the fastest way to get a working call for "the data behind this chart".
- The chart-measures endpoint (the one integrators ask about) enumerates a chart's measures — noting a known gap: it returns the chart's instantiated model measures; a parameter to return template-level measures has been requested and is on the wishlist, not shipped. Design around instance measures.
Authentication and authorisation#
Calls execute as an authenticated user, and Infohub's group scoping applies — the API returns what that user may see, which is exactly why API access is preferable to direct SQL for anything user-facing.
For a service integration: use a dedicated Infohub user with membership scoped to precisely the content the integration needs (see Users, Groups, and Access), authenticate as the client does (Windows auth against the server; capture the working pattern from dev-tools in your environment), and treat that account like any other integration credential — registered, rotated deliberately, never shared with a human.
The rules for building on it#
The API exists to serve Infohub's own client, which sets the contract honestly:
- It is version-coupled. Routes and payload shapes serve the shipped client and can change between releases without an API deprecation cycle. Pin what you use, re-verify per upgrade (add your calls to the same pre-upgrade inventory as external SQL queries).
- Read, don't write. Write endpoints exist for the client's needs (form entry, comments); driving them externally recreates the client badly. External data entry belongs in forms; external data export at scale belongs in consumers.
- It is a query interface, not a firehose. Polling every measure every minute through chart endpoints is the wrong architecture — that is what consumers are for. The API's sweet spot: on-demand reads (a wallboard, an Ignition screen embedding an Infohub chart's data, a report pulled hourly), where the request pattern resembles a user.
- Exports are renders. The export endpoint returns exactly what the browser would show — same rendering path — which makes it the clean way to embed a finished Infohub chart image elsewhere on a schedule.
Choosing the right pipe#
| Need | Use |
|---|---|
| Another system continuously receives values | Data consumer |
| A report/BI tool reads history in bulk | SQL views (read-only, security bypassed — grant deliberately) |
| An application shows Infohub data on demand, per user | This API — scoping applied, chart-shaped |
| A scheduled image/PDF of a chart elsewhere | Export endpoint |
| Building/auditing the model programmatically | The Config CLI |
Worked example — chart data into another tool#
- Open the target chart in the web client; capture its data request in dev-tools.
- Replay it with the integration user's credentials; confirm the JSON.
- Parameterise period bounds the way the client does.
- Handle the two legitimate non-data outcomes: an empty period (real absence) and a 401/403 (scoping — the integration user cannot see that content).
- Record the exact route + payload shape in the integration's contract file, with the Infohub version it was verified against.
That last step is the upgrade insurance for rule 1 — the whole cost of the version coupling is carried by knowing, per upgrade, what to re-verify.