Gundi supports Rules, which are conditions that govern how data moves from a source to a specific destination. With Rules, you can filter or transform observations before they arrive, ensuring each destination receives only the data relevant to it.
What kinds of Rules are available?
Currently, Gundi supports:
Field Mapping Rules: These Rules let you reshape incoming observation data
before it reaches its destination. Optionally, you can apply conditional logic: when a condition
is met, a transformation is applied. For example, you might rename a source field to match what
the destination expects, or assign a fixed value to a field when a specific condition is
true.
Source Filters: These Rules let you decide which sources reach a destination and which ones Gundi skips. You can block specific sources, or allow only specific sources.
Note: Webhook integrations also configure a field mapping while defining the webhook itself, to interpret the incoming payload. That mapping is described in Webhooks; the Rules on this page apply afterwards, per destination.
In the future, Gundi will also support:
Geographic Filtering: Only forward observations that fall within a defined geographic area.
and more.
Considerations
- You can add one rule at a time. The supported types are "Field Mapping" and "Source Filters." More rule types are coming in future releases.
- To get the most out of field mapping, you'll need some familiarity with our API schema. We're improving the UX/UI in upcoming releases to make it more accessible to everyone.
1. How to set up Field Mapping
- Navigate to your Route from the Routes list.
- On the Configurations tab, find the arrow between the data provider and the destination you want to configure, and click the button on it.
- Select Add Rules (or Field mapping under Rules, if rules already exist).
- Click New Rule and select “Field Mapping”.
- Follow the on-screen steps, then click Save Rule.
Example: Mapping Event Types to destination-specific values
In this example, the rule updates the event_type field on Events before they reach
the destination.
The source system uses generic Event Type values like fire and deforestation. The destination,
however, expects its own specific values (gfwfire_rep and
gfwglad_rep). The rule handles this translation automatically:
| When source “type” value is… | Send this Event Type value instead |
|---|---|
| fire | gfwfire_rep |
| deforestation | gfwglad_rep |
If an Event arrives with a type that doesn't match any of these mappings, send a default value
instead ( gfw_rep in the example below, see image)
This means the destination always receives Event Types in the format it expects, without any changes needed on the source side.
2. How to set up a Source Filter
- Navigate to your Route from the Routes list.
- On the Configurations tab, click the arrow between the data provider and the destination.
- Under Rules, choose Source filters, then Add Rule.
- Pick a mode, choose your sources, then save the rule.
There are two modes:
- Block specific sources: every source reaches the destination except the ones you block. New sources get through automatically.
- Allow only specific sources: only the sources you allow reach the destination. Everything else is blocked, including new sources.
While you edit the rule:
- The All, Blocked and Reaching tabs show counts, and a search box helps you find a source fast.
- If a source hasn't sent any data yet, you can add it by hand straight from the editor.
Once the rule is saved, the arrow shows a Source filter badge and the Configurations tab shows a summary of the rule.
Continue Learning
| Account Profile |
