---
title: Forwarders
slug: concepts/forwarders
docTags: B-yfyjgUWqCcM4gCHVQz5,NdAmj9E8yTRkwQ9gl8SF9
createdAt: 2025-08-18T13:17:17.695Z
---

## What is a Forwarder?

A **Forwarder** in Factry Historian defines **which data** should be sent to a [Sink](docId\:uHMCdTK0tRx-qUIpd8PEY), and **how** that data should be structured. Where Sinks handle **where** data goes (e.g. MQTT broker), Forwarders handle **what data is included** and **how it is formatted**.

Think of a forwarder as the **logic layer** between your data and the output destination.

## Why does it matter?

Not every external system needs every piece of data. With Forwarders, you can:

- Select specific [Measurements](docId\:XQWLEmDcNfff3-0H-GMmS), [Calculations](docId\:OpIoDkGNNgYjeDX6zkg_D), [Asset Properties](docId\:Cr6HbrDSl8FsuVlVm20IF) or [Events](docId:0Ith2zLcAIs5YYwhSdTjE) to be included
- Format data (e.g. as JSON, in the case of a generic MQTT sink), see [generic MQTT](docId\:uHMCdTK0tRx-qUIpd8PEY) 
- Split different data streams across multiple sinks with different rules
- Control the structure of outgoing messages

This makes it possible to build targeted, efficient, and decoupled integrations without duplicating configuration or exposing your entire Historian.

## How does it fit in the system?

Forwarders are attached to a Sink, and define:

- **What data** should be sent (using [Labels](docId\:Zb70hNsdFNj3sJ42mYjXI), Asset Properties, or Events)
- **What format** the output should follow (plain JSON or Sparkplug B)
- **How frequently** the configuration should be reloaded

The Sink simply sends what the Forwarder tells it to, in the form defined by the Forwarder.

## Example

You have two MQTT Sinks:

1. A **local broker** for exposing data locally
2. A **corporate broker** for KPIs and energy tracking

You configure two Forwarders:

**Forwarder A** (connected to local Sink):

- Selects all Asset Properties under Line1.
- Uses a JSON format deemed fitting for the site's use cases.

**Forwarder B** (connected to corporate Sink):

- Selects only OEE and energy KPIs for all lines in the site
- Formats them using the JSON structure defined by the corporate guidelines
- Only sends [Event](docId:0Ith2zLcAIs5YYwhSdTjE) data

This allows the same system to support both high-resolution data egress and low-resolution corporate integration, using tailored outputs from the same source data.

## When you use it

You use Forwarders to configure what data leaves the Historian over MQTT:

- When you have multiple Sinks that need different subsets of data
- When you need to control structure and formatting for outgoing messages
- When you want to reuse the same Sink with different categories of data sent to different topics

## Common misconceptions

- Forwarders do not send data on their own; they work through Sinks.
- You can have multiple Forwarders per Sink, each with different settings.
- Forwarders do not modify the original time-series data, only what is published.

## Best practices

- Use clear naming for Forwarders.
- Avoid overlapping rules unless needed. One Forwarder per purpose is easier to maintain.
- Verify your JSON message structure with other stakeholders in the organization, to confirm compliance with their use cases.
- Test outputs thoroughly before going live with third-party integrations.

## More information

- [Creating a forwarder](docId\:Xalp36b2qlv9pDGO83p4c)