Parser

Use the Parser step to extract values from text-based data — typically the JSON or XML response of an upstream HTTP Request, but also CSV-like text, log lines, or any payload you'd otherwise need to read by hand. The step pulls one or more named values out of the input and exposes them as outputs that subsequent steps can reference like any other SmartField.

Typical use cases:

• Pull individual fields out of a REST API JSON response (status, ID, list of items).
• Read SOAP XML response bodies — including documents that use namespaces.
• Process incoming webhook payloads.
• Mine values from unstructured text (e.g. an e-mail body, a log line) with a regular expression.

The Parser is the natural counterpart to the Expression step: Expression composes values, Parser decomposes them.

Configure the step

Open the flow editor, add Parser, and fill in the configuration card.

Description

• Purpose: Make it obvious what this Parser instance is meant to extract.
• When to fill it: Always. The description shows up in the editor and execution history.
• Tips: Name the source and intent, for example, Parse SAP order response.

Parser Type

• Purpose: Picks the selector language used by all lines of this step.
• Options:
  • JsonPath — for JSON payloads. Use selectors like $.id, $.items[*].name.
  • XPath — for XML / SOAP payloads. Use selectors like /Envelope/Body/Result.
  • RegEx — for free-form text. Use a .NET regular expression with optional capture groups.
• When to fill it: Required. The choice applies to every line in the step.

Input

• Purpose: The text to parse.
• When to fill it: Required.
• Tips: Reference an upstream output — most often the responseBody of an HTTP Request — using a SmartField. The step resolves SmartFields before parsing, so the Input field can be entirely templated.

Lines

A list of (Output Name, Selector) rows. Each row produces one or more outputs.

• Output Name: The name under which the extracted value(s) will be available in following steps. Up to 30 characters.
• Selector: The JsonPath / XPath / RegEx expression. Up to 2048 characters.

Namespace Overrides (XPath only)

The Namespace Overrides part is shown only when Parser Type is XPath. By default the step auto-discovers all namespaces in the input and registers them under the prefixes the document itself uses. Override entries take priority and are needed only when the auto-discovery doesn't fit your needs.

• Prefix: The prefix you'll use in your selectors. Up to 20 characters.
• URI: The namespace URI it maps to. Up to 250 characters.

When the Namespace Overrides list contains at least one entry, only the override entries are registered — auto-discovery is disabled for the step.

How outputs are named

Parser Type	Match	Output
JsonPath	scalar value or object	{name}
JsonPath	array	{name}[0], {name}[1], …
XPath	any number of nodes	{name}[0], {name}[1], …
RegEx	any number of matches	{name}[0], {name}[1], …

The asymmetry on the JsonPath row is intentional: only JSON lets us tell – when the step runs – whether a value is a single value, an object, or an array. XPath always returns a node list and RegEx always returns a match list, so both stay consistent with the indexed form.

The exact indexed outputs aren't listed at design time — the count depends on the data. To consume the list, either reference a known fixed index in the next step, or feed the array name into a For Each Loop step.

Parse failures

Malformed JSON or XML aborts the step via the standard error path — the same way every other AutoFlow step signals failure. The Execution Step is marked Error, and the flow follows whatever error handling you've configured upstream of the step.

No-match behaviour

If a selector doesn't match anything, the corresponding named output is created with an empty string. This is consistent across JsonPath, XPath, and RegEx, so following steps can read the output unconditionally.

Working with XML namespaces

XML payloads — SOAP responses in particular — use namespaces, and XPath has strict rules about how prefixed names match. The Parser ships with three behaviours that make real-world XML easy to handle:

1. Auto-discovery. The step walks the document, collects every namespace URI it sees, and registers each one under a prefix in an XmlNamespaceManager for evaluation. The first time a prefix is encountered it wins; if a later subtree reuses the same prefix for a different URI, the second URI is registered under a synthetic suffix (n → n2 → n3 → …).
2. Default-namespace transparency. Plain XPath wouldn't match /Envelope/Body/Result against a SOAP envelope with xmlns="http://www.w3.org/2003/05/soap-envelope" — XPath treats unprefixed names as "no namespace", but the elements do have one. The Parser rewrites every unprefixed segment in your selector to use local-name(), so /Envelope/Body/Result becomes /*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='Result'] under the hood and matches as you'd expect.
3. Override list. When auto-discovery doesn't fit, fill in the Namespace Overrides part. The override prefixes take precedence and are the only namespaces that get registered.

Edge cases worth knowing:

• The unprefixed-name rewrite handles /, //, predicates ([…]), attribute prefixes (@), and existing prefixed names. Unusual XPath constructs (axis specifiers like ancestor::, namespace nodes) are left untouched — register an explicit prefix override if you need them.
• Predicates that refer to attributes don't need namespaces in most documents, because XML attributes default to "no namespace" unless they themselves use a prefix.

Worked examples

REST API response

A JSON response from an order-management API:

{
  "status": "ok",
  "order": {
    "id": "ORD-42",
    "items": [
      {"sku": "ABC", "qty": 1},
      {"sku": "DEF", "qty": 2}
    ]
  }
}

A Parser step on this input with JsonPath and three lines:

Output Name	Selector
status	$.status
orderId	$.order.id
skus	$.order.items[*].sku

Produces:

• status = ok
• orderId = ORD-42
• skus[0] = ABC
• skus[1] = DEF

SOAP response

A weather service response with a default namespace:

<Envelope xmlns="http://www.w3.org/2003/05/soap-envelope">
  <Body>
    <GetWeatherResponse xmlns="http://example.com/weather">
      <Temperature>23</Temperature>
    </GetWeatherResponse>
  </Body>
</Envelope>

With XPath and the selector /Envelope/Body/GetWeatherResponse/Temperature, the auto-discovery and default-namespace rewrite both kick in — the output is temperature[0] = 23. No namespace registration is required from you.

RegEx mining

Plain text input Order ABC-123 shipped on 2026-04-15. with RegEx selector Order (\S+) shipped on (\d{4}-\d{2}-\d{2}) and Output Name order produces:

• order[0] = ABC-123 (first capture group of the only match)

If you want both groups, write two lines with the same pattern but anchor the second one with a non-capturing wrapper, or post-process with a second Parser line targeting the date format.

Tips

• For SOAP integrations, pair a Parser step right after the HTTP Request step. The HTTP step's responseBody becomes the Parser's Input.
• For JSON arrays you'll iterate over, use the array selector and feed the result name into a For Each Loop.