Destinations
An outgoing connection sends machine data from the Collector to one of your own systems: an ERP, an MES, a data platform or your own API. Collect a value once and use it in UpBlue and in the system that plans or books your production, for example the good-parts counter of a packing line going straight into your ERP.
The Collector sends from inside your factory network, so the target can be a system on that network or a service on the internet. It sends one HTTP request per message. For a target on the internet it can also send via the UpBlue proxy, see below.
Destinations do not read anything. The Routes card on the destination page asks What should this destination receive?: pick sites, sources or tags, and UpBlue keeps that as a route. Tags added later that match are sent too.
Delivered by
Delivered by says which Collectors send to this destination.
- This collector: one Collector delivers. Choose it for a system on that Collector’s network, such as a local MES or a broker in one hall. Only the tags of that Collector reach this destination.
- All collectors: every Collector of the organisation sends the tags it reads to this destination. Choose it for a broker or API that every site reaches, such as your Unified Namespace broker, or for a destination on the internet. For a destination on the internet, usually also choose Via the UpBlue proxy, see below.
For example: ten machines on ten Collectors feed one UNS broker. That takes one MQTT out destination, delivered by all collectors, and one route “everything → UNS”. A Collector you pair later delivers it too, without a deploy.
With All collectors, Start destination (or Update destination), Stop destination and Test connection act on every Collector at once and show the result per Collector. The destination page shows per Collector whether it is online, when it was last seen and which revision it runs, how many of its messages failed and how many wait in its queue, and what goes wrong there, such as a target that refuses its credentials. So a site whose firewall blocks your system stands out. A Collector that has not stored the latest revision, because it is offline or the change did not reach it, is marked Behind and catches up by itself when it connects again. You change Delivered by at the top of the destination page, next to Start destination and Stop destination, while the destination is stopped.
Delivery
The Collector keeps every message on its disk until your system has accepted it. When your system is down, the messages wait and are sent when it is back, so a maintenance window on your ERP does not cost you production data.
- Several at once. The Collector sends up to 8 messages at the same time, so a busy line keeps up. Messages can arrive out of order: sort on the time in the message.
- Duplicates. After a retry or a Collector restart, a message can arrive twice. Every message carries an id that stays the same, in the
Idempotency-Keyheader and as{{id}}in a template. Use it to drop the second copy. - Wrong credentials. When your system answers 401 or 403, the Collector pauses this connection and keeps trying one message, with growing pauses. Nothing is thrown away; fix the credentials and the backlog follows.
- Rejected message. When your system answers another 4xx (for example 400 Bad Request), that one message becomes a failed delivery on the connection page and the next messages are sent as normal. See Undelivered messages.
Stopping an outgoing connection throws away the messages that were still waiting on the Collector. Deploying a change keeps them: they are sent with the new settings.
From the Collector or via the UpBlue proxy
By default the Collector sends to your system itself. Choose Via the UpBlue proxy when:
- your factory firewall only lets the Collector reach UpBlue, not your system;
- the credentials must not be stored in the factory: with the proxy they stay in the UpBlue cloud;
- your system signs in with OAuth2 sign-in (see Authentication), which only works via the proxy;
With the proxy the Collector hands each message to UpBlue, and UpBlue sends it to your system. Your system must then be reachable from the internet: a system on the factory network cannot be reached this way.
When your system cannot be reached or asks to wait, UpBlue keeps the message and tries again, less often over time, for up to 24 hours, then moves it to Undelivered messages. A message your system rejects (a 4xx) goes there at once.
Undelivered messages
The Flow card shows the destination in red when messages were not accepted, the same way for both ways of sending: the messages your system rejected (a 4xx), and with the proxy also the ones UpBlue gave up on after its retries. You see them under Flow on the connection page and on every tag page whose data goes to this destination. They are kept 7 days. Messages lists them with what your system answered; Retry sends them again once the cause is fixed, Discard throws them away. While the connection is stopped nothing is retried; the messages wait until you deploy it again. A message the Collector could not deliver goes back to that Collector on a retry; an older Collector must be updated first.
Delivered by all collectors, every Collector keeps its own failed messages. Messages shows which Collector holds each one and filters on one Collector; Retry and Discard then act on that Collector’s messages only. Messages next to a Collector on the destination page opens that list. A retry of all messages goes on when a Collector is offline or does not run the destination: that Collector’s messages stay listed, and the notice names it and says why.
Create a Connection
Name connection
A connection is created within an organisation. Go to the UpBlue Management Environment to open an organisation. Go to Destinations under Data Collection to create a destination.
Select HTTP out and give the destination a name. This name is only for identification and can be changed later.
Delivered by
Choose This collector and pick the Collector, or All collectors, see Delivered by. Created from a Collector page, that Collector is already chosen.
The destination opens. In its Routes card, choose what it receives, see Routes.
Connection details
Fields
Address
The URL the Collector sends to, for example https://erp.example.com/api/readings.
Method and Content type
POST (default), PUT or PATCH, and the Content-Type header, application/json by default.
Headers
Extra request headers your system needs, for example X-Tenant: plant1. Headers are not secret: put a key or password under Authentication.
Delivery
From the collector (default) or Via the UpBlue proxy, see above.
Authentication
How your system is signed in to. Secrets are stored encrypted. From the Collector, they are only sent to the Collector; via the proxy, they stay in the UpBlue cloud.
| Authentication | What is sent |
|---|---|
| None | Nothing |
| Basic | Username and password (Authorization: Basic) |
| Bearer token | Authorization: Bearer <token> |
| API key | The key in a header you name, X-API-Key by default |
| OAuth2 client credentials | Gets a token from the Token URL with the Client ID, Client secret and optional Scopes, and renews it before it expires |
| OAuth2 sign-in (authorization code) | Via the proxy only. Fill in the Authorize URL, Token URL, Client ID, the Client secret (empty for a public client) and Scopes, then click Connect account and sign in, or paste a refresh token you got from your IT department. UpBlue keeps the sign-in and renews its tokens. |
Ask your IT department for a service account or an app registration, not the login of a person: when that person leaves, the connection stops working. With OAuth2 sign-in every message reaches your system as the account that signed in.
Payload format
The shape of each message. The form shows a preview.
UpBlue (default) sends the message as UpBlue builds it:
{"value": 21.5, "kind": 0, "time": "2026-10-23T14:02:03Z", "tag": "temperature", "label": [{"key": "site", "value": "plant1"}]}Flat puts the labels in one object, which most systems read more easily:
{"tag": "temperature", "value": 21.5, "time": "2026-10-23T14:02:03Z", "labels": {"site": "plant1"}}Custom template lets you write the JSON your system expects, with placeholders. There is a template for data and one for events; an empty template sends that kind in the UpBlue format.
{
"MachineId": "{{label.unit}}",
"Counter": "{{tag}}",
"Quantity": "{{value}}",
"BookedAt": "{{time}}",
"Reference": "{{id}}"
}| Placeholder | Data | Events | Value |
|---|---|---|---|
{{id}} | ✓ | ✓ | The message id, the same on every retry |
{{tag}} | ✓ | ✓ | The tag name |
{{time}} | ✓ | ✓ | The time of the value, in the chosen Time format |
{{label.<key>}} | ✓ | ✓ | A label, for example {{label.site}}; null when the value has no such label, or empty text when the placeholder is part of a longer string |
{{connection}} | ✓ | ✓ | The id of this outgoing connection |
{{value}} | ✓ | The value | |
{{kind}} | ✓ | 0 for a number, 1 for text | |
{{rule}} | ✓ | The id of the rule | |
{{state}} | ✓ | started or stopped |
A placeholder that is the whole text between the quotes keeps its type: "{{value}}" sends the number 21.5, not the text "21.5". Inside longer text it becomes text: "{{value}} kg" sends "21.5 kg".
Time format
ISO 8601 (default, 2026-10-23T14:02:03Z), Unix milliseconds or Unix seconds.
Methods, headers, authentication, the payload format and the time format need Collector version 1.8.0 or later. An older Collector ignores them: it sends the UpBlue format without signing in. The form warns you; update the Collector from the Collector page.
Test connection
The Collector sends one example message in your payload format to the address, with the method, headers and authentication you set, and shows the answer of your system. Delivered by all collectors, every Collector sends one and you see the answer per Collector, so a site whose firewall blocks your system stands out. Via the UpBlue proxy, UpBlue sends it, with the settings as they are saved now. A 401 means the credentials are wrong, a 400 that your system does not accept the message shape.