Integration: REST, SOAP, OData and Mapping
REST calls
Call REST supports GET, POST, PUT, PATCH and DELETE, with URL parameters, headers and a body that can be a string, a file or an export mapping. Response handling is configured per status-code range: return nothing, store the body in a string variable, or import it with a mapping. Set Content-Type and Accept explicitly; they are not inferred from the mapping.
Mappings
JSON and XML structures live in the integration pane and are reused by import and export mappings. Map automatically to bootstrap, then set each value's source: variable, attribute or constant. Import mappings only create objects in memory - commit them if they must persist. For polymorphic payloads, model the choice as inheritance and let the mapping resolve the subtype.
OData and SOAP
Published OData services expose chosen entities, attributes and associations with their own authentication and allowed roles; consumers use $filter and $expand. Consuming OData is usually a REST call. SOAP is WSDL-driven: importing a WSDL creates message definitions and mappings that Call web service consumes.
Worked example
A POST to /orders returns 201 with a body containing id. Response handling maps 200–299 into OrderResponse (non-persistent) and stores it in $Response; 400 imports ErrorResponse and raises a custom error with its message; 500 logs and shows a retry message. Reasoning: separate mappings per range let the flow read a structured error rather than parse a string.
Traps
Forgetting to commit imported objects; date and timezone format mismatches (use ISO 8601 or map via a microflow); assuming a mapping validates content, so no checks are added; ignoring non-2xx responses so the flow continues with an empty object.