---
title: c Validator - XSD
description: Available connectors
documentId: ipaas-validator-xsd
locale: en-US
---

The [**Validator**](https://camel.apache.org/components/4.14.x/validator-component.html#_endpoint_options) component ensures the structural integrity and compliance of data (XML payloads) exchanged in an integration. It intercepts messages that do not conform to the XSD contract, preventing errors in target systems.

## How integrations with XSD Validator work

When integrating the XSD Validator into a flow, every incoming XML message is automatically validated against the XSD schema defined in a resource file (see how to [create a resource](/docs/integrations/ipaas-resources).) If the message is compliant, processing continues as normal. Otherwise, the flow is interrupted and a validation exception is thrown, preventing invalid data from reaching the target system.

This approach ensures that only correct and properly formatted information is processed, increasing the reliability of integrations and making it easier to identify data issues early in the flow.

This allows you to create more robust integration flows that validate data contracts (Schemas) and protect legacy systems and business partners from malformed messages ("Garbage In, Garbage Out").

**URI Syntax**: `validator:resourceUri`

### Main fields

*Path parameters*

| **Name** | **Description** | **Default** | **Type** |
|----------|-----------------|-------------|----------|
| `resourceUri` (producer)| (required) Path to the definition file (e.g., `sample.xsd`). | — | String |

*Query parameters*

| **Name** | **Description** | **Default** | **Type** |
|----------|-----------------|-------------|----------|
|`errorHandler` (advanced)| To use a custom `org.apache.camel.processor.validation.ValidatorErrorHandler`. The default error handler captures errors and throws an exception. | — | ValidatorErrorHandler |

### Example

<Steps>
<Step>
The flow starts when an HTTP POST request is made to the `/validate` endpoint.
</Step>
<Step>
The received message body is sent to the Validator component, which validates the XML using the `sample.xsd` resource file.
</Step>
<Step>
If the message is correct (according to the XSD), the flow continues as normal.
</Step>
<Step>
If the message does not conform to the XSD, a validation exception occurs.
</Step>
<Step>
When the exception happens, the flow catches the error and sets the response body to "Failed", indicating that validation was unsuccessful.
</Step>
</Steps>

```yaml
- from:
    uri: "rest:post:/validate"
    steps:
    - doTry:
        steps:
        - to:
            uri: "validator:sample.xsd"
        doCatch:
        - exception:
          - org.apache.camel.support.processor.validation.SchemaValidationException
          steps:
          - setBody:
              constant: Failed
```

![](https://creative-ball-51b3fc85c0.media.strapiapp.com/validator_connector_1a7612576b.png)

In this other example, the Validator component is used directly in the flow. If the XML does not comply with the XSD schema, a validation exception will be automatically thrown by the component, which can be handled by a global Camel error handler or result in a standard HTTP error:

```yaml
- from:
    uri: "rest:post:/validate"
    steps:
    - to:
        uri: "validator:sample.xsd"
```

If the message does not conform to the XSD, the Validator throws a ValidationException and the flow is interrupted.

#### XSD Schema

See the XSD schema configured as a **resource** in the example integration:

```xsd
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
           xmlns:tns="http://tempuri.org/PurchaseOrderSchema.xsd"
           targetNamespace="http://tempuri.org/PurchaseOrderSchema.xsd"
           elementFormDefault="qualified">
 <xsd:element name="PurchaseOrder" type="tns:PurchaseOrderType"/>
 <xsd:complexType name="PurchaseOrderType">
  <xsd:sequence>
   <xsd:element name="ShipTo" type="tns:USAddress" maxOccurs="2"/>
   <xsd:element name="BillTo" type="tns:USAddress"/>
  </xsd:sequence>
  <xsd:attribute name="OrderDate" type="xsd:date"/>
 </xsd:complexType>

 <xsd:complexType name="USAddress">
  <xsd:sequence>
   <xsd:element name="name"   type="xsd:string"/>
   <xsd:element name="street" type="xsd:string"/>
   <xsd:element name="city"   type="xsd:string"/>
   <xsd:element name="state"  type="xsd:string"/>
   <xsd:element name="zip"    type="xsd:integer"/>
  </xsd:sequence>
  <xsd:attribute name="country" type="xsd:NMTOKEN" fixed="US"/>
 </xsd:complexType>
</xsd:schema>
```

The XSD schema defines the structure of an XML document for purchase orders (`PurchaseOrder`). 
Here's what happens in it:

* The main element is `PurchaseOrder`, which must follow the complex type `PurchaseOrderType`.
* `PurchaseOrderType` requires a sequence of elements:
  * `ShipTo`: shipping address, of type `USAddress`, can appear up to 2 times.
  * `BillTo`: billing address, also of type `USAddress`.
  * An attribute `OrderDate`, which must be a date.
* The `USAddress` type defines the address fields:
  * `name`, `street`, `city`, `state` (all strings) and `zip` (integer).
  * An attribute `country`, which must always be "US".
* The default namespace is http://tempuri.org/PurchaseOrderSchema.xsd.

In other words, the XSD ensures that the purchase order XML follows exactly this structure, validating names, types, and required fields. If the XML does not follow this pattern, it will be rejected by the Validator.