Filters
Modules that transform, branch, enrich, or drop records.
Filters run in declared order between the input and the output. Each filter sees one record at a time and can mutate it, drop it, branch on it, or enrich it from an external system.
mapping
Map source fields onto target paths. 13 built-in transforms (trim, lowercase, dateFormat, split, join…).
condition
Branching by boolean expression. then/else chains. Place drop inside a branch to filter out.
loop
Iterate an array field per record, running a nested filter chain for each item. Exposes the item under itemName and the root as record.
script
Inline or file-backed JavaScript via Goja. Full record access through transform(record).
http_call
Per-record HTTP enrichment. Path / query / header keys, LRU + TTL cache, merge / replace / append.
soap_call
Per-record SOAP enrichment. Raw XML body templates, response dataField, cache, merge / replace / append.
sql_call
Per-record SQL enrichment. Positional parameter binding, merge / replace / append, optional cache.
set
Set a field to a literal value. Creates intermediate objects as needed.
remove
Drop one or more fields from each record. Single string or array of paths.
drop
Remove the record from the chain entirely. Usually placed inside a condition branch.
Picking the right filter
| You want to … | Reach for |
|---|---|
| Rename or normalize a field | mapping |
| Set a fixed value on every record | set |
| Get rid of a field | remove |
| Drop the record entirely | drop (usually under a condition) |
| Route records by a boolean expression | condition |
| Walk an array field on each record | loop |
| Look something up from an HTTP API | http_call |
| Look something up from a SOAP API | soap_call |
| Look something up from a SQL database | sql_call |
| Run arbitrary JavaScript | script |
Merge contract of the call filters
http_call, soap_call and sql_call all emit one call per record and fold
the response back into that record. They share a single merge contract, so what
you learn on one applies to the other two:
mergeStrategy | Destination of the response | resultKey |
|---|---|---|
merge (default) | Deep-merged into the record — nested objects merged, response values win conflicts | ignored |
replace | Overlaid on the record's top-level keys — fields absent from the response are preserved | ignored |
append | Nested whole under resultKey | required |
append without resultKey fails cannectors validate for the three filters
alike: none of them picks a destination for you. Outside append, resultKey
has no effect on the merge — but it is still checked: whatever the strategy, it
can never reach into _errors, the key that belongs to the runtime's
error markers. That check runs when the
filter is built, so a reserved resultKey passes cannectors validate and
fails on cannectors run.
See Input → Filters → Output for how filter order affects record flow.