A REST value without quality is lying to your operators
Getting a number out of a REST API and onto a screen is a short job. The part that takes longer to get right is making the screen tell the truth when the API stops answering.
A tag is three things, not one
An Ignition tag carries a value, a quality code, and a timestamp. A quality code is not a single flag: it has a level — Good, Bad, Error or Uncertain — and an integer behind it. Everything downstream can read all three, and some of it does. Each binding driving a component is evaluated for quality, and if that quality becomes poor the component shows an overlay. Operators reading a screen are implicitly trusting all three, even though only the value is printed in large type.
The common way to pull in REST data is a gateway timer script that makes the request and writes the result to a memory tag. That works, and for a quick integration it is often the right amount of effort. The catch is what the tag ends up carrying: on a plain write the tag system assigns Good quality and the write time, unless the script goes out of its way to construct and write a fully qualified value instead.
The failure is silent by default
Consider what happens when the endpoint stops responding, and note that there are two versions of this and neither one helps you.
If the script throws and dies before writing, the tag keeps its previous value at Good quality. If the script catches the error and rewrites the last known value to keep the screen populated, the value is stale but the timestamp advances — a memory tag will generally refresh its timestamp even when the value written is identical. In the first case the number is frozen and looks authoritative. In the second the number is frozen and looks fresh.
Either way, nothing on the screen changes. No overlay, no colour change, no alarm. The number an operator is looking at is an artifact of the last time the network worked, presented with exactly the same confidence as a number from a second ago. That is the whole problem: not that the integration broke, but that it broke in a way that looks identical to working.
Contrast that with a tag whose quality degrades when its source does — briefly to stale, where a recent value may still be useful, then to a bad code. Bad quality is not an alarm by itself; it drives the overlay, and it lets you put a Bad Quality alarm directly on the tag rather than writing an expression tag whose only job is to detect the outage. The platform has this machinery. Data has to arrive carrying quality for any of it to engage.
Whose timestamp is it?
The second thing that goes missing is harder to notice and harder to undo.
Many APIs report when a reading was actually taken. A scale, a lab system, a utility meter, a weather service — the payload often includes an observation time that is not the time you fetched it. Store the fetch time instead and every historical record is displaced by however long the gap was, with that displacement varying by poll interval and network conditions.
There is a platform detail worth knowing before you rely on source timestamps at all. How Ignition treats an out-of-sequence observation is governed by Allow Back-fill Data on the realtime tag provider, which is off by default. Back-fill is exactly what you reach for when a source reports out of sequence, which makes its trade worth reading carefully. Turn it on and, in Inductive Automation’s words, out-of-order data “will be stored to history, but will not be used for alarms, scripts, or subscriptions” — so a back-filled reading lands in your trend and never reaches your alarm logic.
Live screens survive timestamp drift. Analysis does not. Line up a REST-sourced trend against a PLC-sourced one to explain an event, and a drifting offset between them turns a clear correlation into an argument. The value was right and the clock was wrong, which is a difficult thing to discover months later and a miserable thing to correct after the fact.
Credentials expire quietly too
Token-based authentication introduces a failure with a timer on it. A token is valid, then it is not, and the endpoint typically starts returning 401. If nothing handles that, values freeze at the moment the token lapsed — and by the logic above, nothing announces it.
This is worth designing for rather than discovering. REST to Tags refreshes tokens ahead of expiry and refetches on a 401, so an expired credential recovers without anyone intervening. It supports static headers such as an API key, and OAuth2 client-credentials.
Give the outage somewhere to show up
Quality on the data tag tells an operator not to trust the number. It does not tell an engineer what went wrong, and those are different audiences with different questions.
REST to Tags exposes per-source diagnostics as tags in their own right — Quality, DataAgeMs, ConsecutiveFailures and LastError under a per-source Diagnostics folder. ConsecutiveFailures can be alarmed on a threshold, which is where the two halves meet — quality drives the overlay, and ConsecutiveFailures gives you the alarm you actually want. One failed poll is weather; a run of them is an outage. Sources are also isolated from each other, so one slow endpoint does not hold up the rest.
The test worth running
Whatever you build or buy, the question is not whether the value arrives. It is what an operator sees during an outage. Unplug the endpoint, wait, and look at the screen. If the number looks exactly as trustworthy as it did before, the integration is not finished, however long it has been running without incident.
Common questions
Why not just use a gateway timer script?
Does bad tag quality raise an alarm on its own?
Does REST-sourced data support history and alarming?
Can it write back to the API?
References
Pulling an API into Ignition tags? REST to Tags requires Ignition 8.3 or later and is free for one API URL with no time limit, so you can watch how it behaves during an outage on your own gateway before deciding.
See REST to Tags