Connection Creator in Structures

A Structure connection runs inside the lead flow itself, while the customer is still filling in the form or the lead is still being processed, and it can shape or gate the data before the lead is finalized.

There are three common purposes for a Structure connection.

1. Validation. Check a field against an external service and, if enabled, reject the lead when the value is invalid.
2. Enrichment. Fill a field with a value pulled from an external source, based on data the customer already provided.
3. Autosuggest. Offer typeahead suggestions while the customer is typing a field.

All three share the same building blocks (httpNode to call the external API, setNode to store the result, conditional edges to branch on the response), but they differ in how the flow ends.

Validation

Ask an external service whether a value the customer entered is valid (a national ID, a bank account, and so on), and use the result to either let the lead continue or reject it.

Pattern

1. startNode (structure).
2. httpNode (GET) calling the validation endpoint, typically with the field value as a query parameter (for example birthId={data_nin} or bankAccount={data_account_number}/{data_bank_code}).
3. Three branches out of the httpNode, based on {status} and {parsedBody.valid}.
   1. Valid. {status} equals 200 and {parsedBody.valid} equals true. This leads to an endNode titled Valid with success: "success".
   2. Outage. {status} matches a 4xx or 5xx pattern (regex \b[45]\d{2}\b). This leads to an endNode titled Outage with success: "success", because a service outage should not automatically reject the lead.
   3. Invalid. {parsedBody.valid} equals false. This leads to an endNode titled Invalid with success: "failed".

The important detail: success on the end node

The success value on the terminal endNode is what actually decides whether the lead gets rejected. In both validation examples (national ID, bank account), the Invalid branch uses success: "failed", which is the setting that rejects the lead when the field does not validate. Valid and Outage both use success: "success", so neither blocks the lead, only a confirmed invalid value does.

This is easy to get wrong, so when building a validation connection, check that:

1. The branch meant to reject the lead is the only one using success: "failed".
2. An outage or an unexpected response does not accidentally inherit success: "failed", or every temporary API hiccup will start rejecting real customers.

Modify (filling a field with an external value)

Take a value the customer already gave (a national ID, a name and birth date, and so on), call an external registry or lookup API, and use the response to fill a different field automatically, for example deriving a company number from a person’s name, or checking whether a person is in insolvency.

Pattern, simple version (insolvency check)

1. startNode (structure).
2. httpNode (GET) calling the lookup endpoint (for example checkInsolvency?birthId={data_nin}).
3. Three branches:
   1. True. {status} equals 200 and {parsedBody.liveRecords} equals 1. A setNode writes {data_insolvency} = "yes", then an endNode titled Valid with success: "success".
   2. False. {status} equals 200 and {parsedBody.liveRecords} equals 0. A setNode writes {data_insolvency} = "no", then an endNode titled Invalid with success: "success".
   3. Outage. Same 4xx/5xx regex as in validation. endNode titled Outage with success: "success".

Note that here, unlike in a strict validation connection, both outcomes (found and not found) use success: "success". Enrichment should not reject the lead just because the lookup came back empty, it should only fill (or not fill) a field. Only use success: "failed" when the absence of a value is itself a genuine reason to reject the lead.

Pattern, with a fallback field and a conditional prefill (company number lookup)

1. startNode (structure).
2. modifyFieldNode to prepare an input the API needs but the customer did not directly provide
3. httpNode (GET) calling the lookup endpoint with the prepared parameters (name, birth date).
4. Three branches:
   1. Outage. {status} matches the 4xx/5xx regex, or {parsedBody.status} equals error. endNode titled Outage.
   2. True. {status} equals 200 and {parsedBody.freelancers.1.ico} is not empty. A setNode writes {data_company_number_imported} = {parsedBody.freelancers.1.ico}.
   3. False. {status} equals 200 and {parsedBody.freelancers.1.ico} is empty. A setNode with no fields set (the field is simply left empty) leads directly to an endNode titled Invalid with success: "success".
5. On the True branch, before the final endNode, a modifyFieldNode applies a do_not_send modification to {data_company_number_imported} as a safeguard. When configuring this kind of guard, make sure the condition actually compares against the live parsed value from the response, not against a hardcoded literal string that happens to look like the field path. If the condition is written as a literal string instead of a template reference, it will never match a real response and the guard becomes dead logic.

Autosuggest (typeahead)

While the customer types into a field (for example a company name), call an external suggestion API on each keystroke or debounce interval and return a list of matching values for the frontend to display as a dropdown.

Pattern

1. startNode (structure).
2. httpNode (POST) sending the partial input to the suggestion API, for example fieldType: COMPANY_NAME, values.COMPANY_NAME: {company_name}.
3. setNode storing the full suggestion list, for example {autocomplete_result} = {parsedBody.suggestions}.

This is the simplest of the three patterns: there is no branching and no rejection logic, the flow always ends in the same single setNode, and the frontend is responsible for rendering the returned list and letting the customer pick one.