> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-xml-payload.md). # Send XML Payload Sends an XML or SOAP-over-HTTP payload to an external endpoint as a workflow step. Use it to integrate with legacy applications that expose XML or SOAP APIs instead of REST or SCIM. The action reuses the [Send REST Request](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-rest-request.md) credential model and captures values from the response via XPath for use by downstream actions. **Example use cases:** * Provision users in an on-premises application with a SOAP web service * Submit payloads to legacy HR or payroll systems * Trigger an XML webhook in an internal ticketing system * Capture an identifier from a SOAP response and pass it to a downstream action ## Settings | Setting | Description | | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Webhook URL | Target endpoint URL. Supports `{attribute_name}` substitution in the path and query string. | | HTTP Method | Request method. POST is typical for SOAP; GET, PUT, PATCH, DELETE, HEAD, and OPTIONS are also supported. | | Authorization Header | Inline auth header (e.g., `Bearer `). Ignored when **REST Auth Credentials** is set: the header is then built from the credential. | | REST Auth Credentials | (Optional) Stored REST authentication credential. Same model as [Send REST Request](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-rest-request.md): `HEADER`, `BASIC`, `BEARER`, `LOGIN_TO_BEARER`, `OAUTH2`. | | Webhook Headers | (Optional) Additional request headers. Applied last, so entries here override defaults: including `Content-Type` (see [Content-Type](#content-type)). | | SOAP Action Header | (Optional) Value for the `SOAPAction` HTTP header, required by some SOAP 1.1 services. | | XML Payload | Request body. Supports `{attribute_name}` substitution; substituted values are XML-escaped automatically. | | Timeout | Request timeout in seconds. Range: 0–3600. `0` uses the driver default. | | Only Send if Any Upstream Changes | When enabled, the request runs only if a prior action in the workflow modified or created resources. Cannot be combined with [Insight Point execution](#insight-point-execution). | | Add Response to Output Entities | Extract XPath-selected values from the response and expose them as entity attributes for downstream actions. | | Output Entity Type | Entity type created from the response. Required when **Add Response to Output Entities** is enabled. | | Response Entity XPath | XPath selecting the parent node that contains the result data. | | Response ID XPath | XPath selecting the entity identifier within the response. | | Response Name XPath | XPath selecting the entity display name within the response. | | Capture All Children As Attributes | (Advanced) Flatten every direct child element and XML attribute under the response entity node into the output entity's attribute map. | ## Content-Type `Content-Type` is hard-coded to `text/xml`. There is no Content-Type field in the action settings. To send a different media type, override the header through **Webhook Headers**. Entries in that map are applied last, so they win over the default. For example, to send SOAP 1.2: | Header key | Header value | | -------------- | ---------------------------------------------------------- | | `Content-Type` | `application/soap+xml; action="urn:example:hr:CreateUser"` | ## Variable substitution The Webhook URL and XML Payload fields accept `{attribute_name}` placeholders. Sources include the source of identity and any prior action in the workflow (including a preceding [Sync Identities](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/sync-identities.md) action). ```xml {employee_id} {email} {department} ``` Transformer expressions (`UPPER`, `LOWER`, `TRIM`, dot notation for nested attributes) work the same way as in Send REST Request. See [Transformers](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/transformers.md). {% hint style="info" %} **Substituted values are XML-escaped automatically.** `<`, `>`, `&`, and quote characters are escaped in identity-derived values, and the substituted document is re-checked for well-formedness before send. No manual escaping is required. {% endhint %} ## Form field substitution (Access Requests only) When a Send XML Payload action is configured as part of an Access Request [catalog definition](/4yItIzMvkpAvMVFAamTf/features/access-hub/configuration.md), the XML Payload can reference values submitted on the request form. The requester provides values (such as a username or role identifier) at request time, and those values are inserted into the payload at execution. Use the `{$form_field.field_name}` syntax inside element or attribute content, where `field_name` matches a field defined on the catalog definition. To configure form field substitution: 1. Author the XML Payload with `{$form_field.*}` placeholders in each element or attribute that takes a requester-supplied value: ```xml {$form_field.email} {$form_field.role_name} ``` 2. On the matching catalog definition, add form fields whose names match the placeholders (`email` and `role_name` in the example above). 3. When a user submits an access request, the value entered for each form field replaces the corresponding `{$form_field.*}` placeholder in the XML Payload before the request is sent. Form field substitution applies to the XML Payload only. It does not apply to the Webhook URL, Authorization Header, or Webhook Headers. Substituted form-field values are XML-escaped automatically, and the substituted document is re-checked for well-formedness before send. Placeholders inside XML comments or `CDATA` sections cannot be safely escaped: a value containing `--` or `]]` can fail the well-formedness recheck, and the action will error. Field names must contain only letters, numbers, and underscores (`role_name` is valid, `role-name` is not). A field whose name contains an unsupported character might be accepted at catalog-definition save time but is not substituted at execution time, and the literal `{$form_field.*}` placeholder is emitted in the payload. If a placeholder references a field that was not provided on the access request, the placeholder is likewise left unchanged. ## XPath response capture When **Add Response to Output Entities** is enabled, the action parses the XML response and runs the configured XPath expressions: | Mapping field | Example | | --------------------- | ---------------------- | | Output Entity Type | `LegacyAppUser` | | Response Entity XPath | `//CreateUserResponse` | | Response ID XPath | `UserId/text()` | | Response Name XPath | `DisplayName/text()` | The extracted entity is added to the workflow context. Downstream actions reference it as `{LegacyAppUser.id}` and similar `{EntityType.attribute}` expressions. For SOAP responses wrapped in a standard envelope, traverse the envelope inline and declare namespace prefixes directly in each XPath expression. There is no separate namespace-registration step: prefixes in your XPath must match the prefixes in the response document as-is. {% hint style="info" %} **Capture All Children As Attributes** flattens every direct child element and XML attribute under the response entity node into the output entity's attribute map, alongside the explicit `id` and `name`. Use it when the returned field set varies and enumerating each one isn't practical. {% endhint %} ## Authentication The action uses the [Send REST Request](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-rest-request.md) credential model. Provide credentials inline via **Authorization Header**, or reference a stored credential via **REST Auth Credentials**: * **No Authentication**: internal services or pre-authenticated URLs. * **Header** (`HEADER`): arbitrary inline header value. * **Basic** (`BASIC`): username and password, base64-encoded. * **Bearer** (`BEARER`): `Bearer `. * **Login-to-Bearer** (`LOGIN_TO_BEARER`): exchange credentials at a login endpoint for a Bearer token, cached for the action. * **OAuth2** (`OAUTH2`): client credentials or other OAuth2 flow. ## Insight Point execution Set **Datasource** to route execution through an Insight Point instead of the control plane. Use this when the target endpoint is unreachable from the Veza control plane. | Setting | Description | | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Datasource | (Optional) Custom Provider data source to route through. Must be configured as an Insight Point Custom Application. When empty, the action runs on the control plane. | {% hint style="warning" %} Insight Point execution cannot be combined with **Only Send if Any Upstream Changes**. Setting both `datasource_id` and the upstream-changes flag is rejected at validation. {% endhint %} ## Save-time validation The XML payload is checked for well-formedness at save time. Common rejections: * Multiple root elements * Non-whitespace text outside the root * Unbalanced or improperly nested tags Validation runs again on the substituted payload at execution time, so a body that becomes ill-formed because of a substituted value fails safely instead of being sent. ## Configuration Add the action through the Policy Editor or the policy update API: * **Policy Editor**: open the policy, choose **Add Action**, then select **Send XML Payload**. * **API**: include the action in the policy's `actions` array. The action type identifier is `SEND_XML_PAYLOAD`. See [Update Policy Configuration](/4yItIzMvkpAvMVFAamTf/developers/api/lifecycle-management/policies/updatepolicyconfiguration.md). ## Limitations * XML only. Use [Send REST Request](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-rest-request.md) for JSON payloads. * `Content-Type` is fixed to `text/xml`; override via Webhook Headers for a different media type. * No separate XML namespace registration: declare prefixes inline in each XPath expression. * Response parsing requires well-formed XML when **Add Response to Output Entities** is enabled. * Streaming, multipart, and MTOM responses are not supported. * Timeout applies to the entire request; failed requests are not retried automatically. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/send-xml-payload.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.