Use XML content modelling when the external API sends or expects XML.

Payloads uses the same Element concept for XML that it uses for other body formats, but XML has a few extra rules. Element names, nesting, order, document-level settings, and attributes can all matter to the receiving system. A body that looks close to the expected XML can still fail if one of those details is wrong.

Start by setting the right content type, then build the XML structure in the Payload UI so the generated Job body can be compared with the external system's schema or example request.

For the shared Element model, see Understand Elements and mapping.

Set the relevant Payload content type to XML.

Use Outbound Content Type when Payloads sends XML to another system. Use Inbound Content Type when Payloads receives XML from another system.

The content type tells Payloads which body parser or serialiser to use when the Payload runs. Without this, Payloads cannot know whether the Element tree should be treated as XML or as another supported body format.

XML Payloads can include document-level settings such as XML declaration, processing instructions, and doctype when the receiving system requires them.

Use the Payload XML fields when the API expects document-level XML details.

XML Declaration controls whether the generated document includes a declaration such as version and encoding. XML Doctype controls the document type declaration when the receiving system requires one. XML Processing Instructions can be used when the receiving system expects processing instructions at the top of the document.

Only set these fields when the external API documentation requires them. Most APIs that accept XML do not need every XML document option, and adding unnecessary document-level values can make troubleshooting harder.

The root $ represents the generated document structure.

Use Object Elements for XML elements that contain child values. Use String, Number, Boolean, or Null Elements for leaf values. Where the XML contract requires attributes, model those values as attributes in the Element tree rather than as ordinary child elements.

Keep names precise. XML is sensitive to element names, attribute names, nesting, and ordering, so small changes can produce a body the receiving system rejects.

Use XML attributes when a value belongs on the XML tag rather than inside a child element.

For example, if the target XML needs:

In that shape, id belongs to the customer tag itself, while Acme is the element value.

Use attributes only when the XML schema or API documentation expects attributes. Do not convert ordinary JSON-style fields into attributes unless the receiving system requires that shape.

XML leaf values can be mapped from static values, Data Query fields, Dynamic Inputs, inbound Elements, Credential values, or Transformations depending on where the XML body is used.

Use Transformations when the XML API expects a different value format from the source data. Common examples include date formats, code mappings, boolean formatting, and amount formatting.

After a test run, compare the Job body with the external example. That is usually the fastest way to spot incorrect nesting, missing attributes, or values that were transformed into the wrong format.

Use sample XML to check the shape, but review the Element tree after import.

Samples often omit optional elements or show only one entry inside a repeating section. If the real API can send or receive multiple entries, make sure the relevant Element is modelled as an array-like repeating structure and mapped to a repeating source.

Before testing, check that:

After testing, compare the Job body with the external system's XML documentation or schema.