XML API

How the XML feed API works — message types, schemas, sanitised samples, and the two-phase acknowledgement contract.

How XML messaging works

The XML API is the core feed channel into Paxon. Each feed is a raw XML payload POSTed to a per-client endpoint, validated against an XSD, and acknowledged. It carries the four inbound message types that set up and drive fulfilment: catalogue (CAT), purchase orders (PO), returns (RMA) and sales orders (NO).

For the wider picture — how inbound feeds, outbound feeds and the REST services fit together — see the Integration flow guide. Every endpoint, request schema and response example is in the interactive reference.

Endpoint and authentication

Each message type has its own path under /feeds/{clientId}/. The clientId is the client identifier Paxon assigns during onboarding (max 10 characters).

Message	Endpoint	Root element	Schema
CAT	`POST /feeds/{clientId}/CAT`	`itemMaster`	/xsd/CAT.xsd
PO	`POST /feeds/{clientId}/PO`	`vendorOrder`	/xsd/PO.xsd
RMA	`POST /feeds/{clientId}/RMA`	`returnMerchandiseAuthorization`	/xsd/RMA.xsd
NO	`POST /feeds/{clientId}/NO`	`orderRequest`	/xsd/NO.xsd

Unlike the OAuth2-secured REST services, the XML API authenticates with an API key sent in the X-API-KEY request header. Paxon shares the key during onboarding. The payload content type is text/xml (or application/xml).

curl -X POST https://rucapi.fulfilit.cloud/feeds/<clientId>/CAT \
  -H 'X-API-KEY: <api_key>' \
  -H 'Content-Type: text/xml' \
  --data-binary @cat.xml

A staging host, rucapi.stage.fulfilit.cloud, is available for testing before you go live on rucapi.fulfilit.cloud.

Partners that cannot POST over a live HTTP connection can exchange the same XML feeds over SFTP instead — the message types, payloads and XSDs are identical, only the transport differs. Paxon provisions the SFTP credentials and folder layout during onboarding.

The two-phase acknowledgement

Every feed is acknowledged twice:

A synchronous response to the POST — an apiResponse (the ACK) carrying a correlation token and the parse-time disposition. This tells you the payload was received and whether it passed initial validation.
An asynchronous outbound feed later, once Paxon's downstream systems have processed the message. Order status flows back as OS feeds, goods receipts as GR, returns received as RS, and so on (see the Integration flow guide).

The synchronous ACK is covered in the Acknowledgements section below. Each message type validates against its XSD before it is accepted; download the schema from the /xsd/ links above and validate locally to catch problems before you send.

CAT — catalogue / item master

The CAT feed is the item master. Send it first: it tells Paxon about your products so purchase orders, returns and sales orders can reference known SKUs. The root element is itemMaster and each item carries identifiers, dimensions, weights and any number of extendedAttributes.

Key fields worth calling out:

clientId — your assigned client identifier, repeated in the payload.
sku — the primary product identifier; PO, RMA and NO payloads reference it.
eanCode and the gtinBarcodes/barcode list — scannable identifiers. An EAN already mapped to a different SKU is rejected (see the rejected CAT ACK).
extendedAttributes/attribute — named flags and values such as IsHazmat, BrandName or ProductCategoryCode.

Schema: /xsd/CAT.xsd

<?xml version="1.0" encoding="UTF-8"?>
<itemMaster xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="CAT.xsd">
	<clientId>ACMEPARTS</clientId>
	<date>2026-06-09T19:15:04+01:00</date>
	<item>
		<sku>SKU0001</sku>
		<altSku>ALT0001</altSku>
		<eanCode>1000000000017</eanCode>
		<name>Example Product 0001</name>
		<weight>23</weight>
		<weightUomCode>kg</weightUomCode>
		<dimensionsUomCode>cm</dimensionsUomCode>
		<height>35</height>
		<length>80</length>
		<width>60</width>
		<productType>P</productType>
		<countryOfOrigin>IT</countryOfOrigin>
		<imageUrl>https://cdn.example.com/thumb?id=SKU0001</imageUrl>
		<captureBatchRef>true</captureBatchRef>
		<extendedAttributes>
			<attribute name="ItemLabelRequired">false</attribute>
			<attribute name="IsHazmat">false</attribute>
			<attribute name="IsBulkyFlag">false</attribute>
			<attribute name="CutToOrder">false</attribute>
			<attribute name="BrandName">Example Brand</attribute>
			<attribute name="ProductCategory">Example Category</attribute>
			<attribute name="ProductCategoryCode">39</attribute>
			<attribute name="VelocityCode">F24</attribute>
		</extendedAttributes>
		<gtinBarcodes>
			<barcode>ALT0001</barcode>
			<barcode>1000000000024</barcode>
			<barcode>1000000000031</barcode>
		</gtinBarcodes>
	</item>
</itemMaster>

PO — purchase order

The PO feed (also called an ASN) tells the warehouse what stock to expect inbound. The root element is vendorOrder and each line references a sku and a qty. Send PO feeds so the warehouse can receive and put away deliveries against them.

Key fields worth calling out:

poNumber — the purchase-order reference; the ACK echoes it as the objectId.
actionType — NEW to create, or an update action against an existing PO.
lines/line — each line carries sku, qty and qtyUom. Every referenced SKU must already exist in RUC (sent via a CAT feed); unknown SKUs are reported in missingSkus.

Schema: /xsd/PO.xsd

<?xml version="1.0" encoding="UTF-8"?>
<vendorOrder xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<vendorOrderId>1000000001</vendorOrderId>
	<poNumber>PO-0001</poNumber>
	<distributionCentre>EEUK01</distributionCentre>
	<clientId>ACMEPARTS</clientId>
	<lines>
		<line>
			<lineId>1</lineId>
			<lineNumber>1</lineNumber>
			<sku>SKU0001</sku>
			<altSku>ALT0001</altSku>
			<productName>Example Product 0001</productName>
			<qty>2</qty>
			<qtyUom>unit</qtyUom>
		</line>
		<line>
			<lineId>2</lineId>
			<lineNumber>2</lineNumber>
			<sku>SKU0004</sku>
			<altSku>ALT0004</altSku>
			<productName>Example Product 0004</productName>
			<qty>2</qty>
			<qtyUom>unit</qtyUom>
		</line>
	</lines>
	<messageId>1000000000000001</messageId>
	<actionType>NEW</actionType>
	<extendedAttributes>
		<attribute name="ClientPurchaseOrderType"><![CDATA[3|PRE]]></attribute>
		<attribute name="SupplierCode"><![CDATA[100]]></attribute>
		<attribute name="PurchaseOrderType"><![CDATA[SUPPLIER]]></attribute>
	</extendedAttributes>
</vendorOrder>

RMA — return merchandise authorisation

The RMA feed pre-authorises a return so the warehouse can receive it against a known reference. The root element is returnMerchandiseAuthorization and each line records what is coming back and why.

Key fields worth calling out:

rmaNumber — the return reference; the ACK echoes it as the objectId. It must be unique (a duplicate is rejected).
returnReasonCode — the disposition reason for the returned line.
quantityReturned and qtyUom — how much is coming back.
orderReference — optional link to the originating order; the RMA is rejected if the referenced order is unknown to RUC.

Schema: /xsd/RMA.xsd

<?xml version="1.0" encoding="UTF-8"?>
<returnMerchandiseAuthorization xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<rmaNumber>RMA-0001</rmaNumber>
	<clientId>ACMEWEAR</clientId>
	<distributionCentre>EEDE01</distributionCentre>
	<orderReference>ORD-0001</orderReference>
	<creationTimeStamp>2026-06-09T18:55:35+01:00</creationTimeStamp>
	<line>
		<lineNumber>1</lineNumber>
		<sku>SKU0006</sku>
		<returnReasonCode>1K</returnReasonCode>
		<qtyUom>unit</qtyUom>
		<quantityReturned>1</quantityReturned>
		<attributeOne>1000000000062</attributeOne>
		<attributeThree>1000000000079</attributeThree>
	</line>
</returnMerchandiseAuthorization>

NO — new order

The NO feed is a sales order for Paxon to pick, pack and ship. Note the XSD root element is orderRequest (not newOrder). It is the richest of the four payloads: a billing and a shipping address, payment summary, totals, and one or more order lines.

Key fields worth calling out:

orderId — your order identifier; the ACK echoes it as the objectId.
actionType — NEW to create the order.
shipToAddress / billToAddress — addresses are validated, including postcode format per country (a malformed postcode is rejected — see the rejected NO ACK).
lines/line — each line references a sku and qty. Unknown SKUs are reported in missingSkus.
distributionCentre and carrierCode — where the order is fulfilled and how it ships.

Schema: /xsd/NO.xsd

<?xml version="1.0" encoding="UTF-8"?>
<orderRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="NO.xsd">
	<orderId>1000000001</orderId>
	<actionType>NEW</actionType>
	<clientId>ACMEPARTS</clientId>
	<externalOrderReference>1000000001</externalOrderReference>
	<catalogId>ACM</catalogId>
	<doNotShip>0</doNotShip>
	<origin>B2C</origin>
	<language>en</language>
	<orderDate>2026-06-09T18:09:00+00:00</orderDate>
	<shippingMethod>EXPRESS</shippingMethod>
	<shippingCost unit="GBP">0</shippingCost>
	<subtotal unit="GBP">0</subtotal>
	<taxes unit="GBP" amount="0">
		<tax type="VAT">0</tax>
	</taxes>
	<totalPrice unit="GBP">0</totalPrice>
	<billToAddress addressId="1000000001">
		<title></title>
		<companyName></companyName>
		<department></department>
		<firstName>Alex</firstName>
		<lastName>Taylor</lastName>
		<address1>1 Example Street</address1>
		<address2>Flat 2</address2>
		<city>London</city>
		<zip>EC1A 1BB</zip>
		<state></state>
		<country>GB</country>
		<phone>447700900123</phone>
		<mobile>447700900123</mobile>
		<email>alex.taylor@example.com</email>
	</billToAddress>
	<shipToAddress addressId="1000000001">
		<title></title>
		<companyName></companyName>
		<department></department>
		<firstName>Alex</firstName>
		<lastName>Taylor</lastName>
		<address1>1 Example Street</address1>
		<address2>Flat 2</address2>
		<city>London</city>
		<zip>EC1A 1BB</zip>
		<state></state>
		<country>GB</country>
		<phone>447700900123</phone>
		<mobile>447700900123</mobile>
		<email>alex.taylor@example.com</email>
	</shipToAddress>
	<payments>
		<payment type="CC">
			<tender><![CDATA[N/A]]></tender>
		</payment>
	</payments>
	<lines>
		<line>
			<lineNumber>1</lineNumber>
			<sku>SKU0001</sku>
			<qty>1</qty>
			<lineTotal unit="GBP">7.99</lineTotal>
			<taxes unit="GBP" amount="0">
				<tax type="VAT">0</tax>
			</taxes>
			<unitNetPrice>7.99</unitNetPrice>
			<extendedUnitNetPrice>7.99</extendedUnitNetPrice>
			<unitGrossPrice>0</unitGrossPrice>
			<qtyUom>unit</qtyUom>
			<stockPool>A</stockPool>
			<extendedAttributes>
				<attribute name="IsHazmat"><![CDATA[false]]></attribute>
				<attribute name="ProductCategoryCode"><![CDATA[1165]]></attribute>
			</extendedAttributes>
		</line>
	</lines>
	<distributionCentre>EEUK01</distributionCentre>
	<carrierCode>ANY</carrierCode>
	<extendedAttributes>
		<attribute name="WebOrderId"><![CDATA[1000000001]]></attribute>
		<attribute name="IncotermName"><![CDATA[DDP]]></attribute>
		<attribute name="PackingSlipLanguage"><![CDATA[EN]]></attribute>
		<attribute name="PrintPricesOnPackingSlip"><![CDATA[0]]></attribute>
		<attribute name="Priority"><![CDATA[2]]></attribute>
	</extendedAttributes>
</orderRequest>

Acknowledgements

The synchronous response to every feed is an apiResponse (the ACK). It always carries a correlation token and a feedType, plus a boolean success. On success the ACK identifies the processed object; on failure it lists the errors. Validate the ACK against /xsd/ApiResponse.xsd.

Accepted

A successful ACK sets success to true and echoes the feedType. For example, an accepted PO:

<?xml version="1.0" encoding="UTF-8"?>
<apiResponse>
	<token>1874c47a69b4413a8cc509f31fa9aaf2</token>
	<success>true</success>
	<feedType>PO</feedType>
	<objectId>PO-0001</objectId>
</apiResponse>

Rejected

A rejected ACK sets success to false and carries an errors list with the verbatim reason. For example, a NO rejected for an invalid postcode:

<?xml version="1.0" encoding="UTF-8"?>
<apiResponse>
	<token>2ac0356b2150ec6415eed9a3926d24aa</token>
	<success>false</success>
	<feedType>NO</feedType>
	<errors>
		<error>Unable to import sales order 100000123! Invalid ship to postcode format given AB12  3CD for the given country (GB - UNITED KINGDOM). Allowed formats are: ...</error>
	</errors>
	<objectId>100000123</objectId>
</apiResponse>

Each feed type carries its own accepted and rejected ACK in the interactive reference — including a CAT rejection (an EAN already mapped to another SKU), an RMA rejection (a non-unique RMA number), and a PO rejection that demonstrates missingSkus (below).

The `objectId` contract

When a feed is processed, the ACK echoes the identifier of the object it acted on in objectId, so you can correlate the response with the payload you sent:

Feed	`objectId` is…
NO	the `orderId` from the payload.
PO	the `poNumber` from the payload.
RMA	the `rmaNumber` from the payload.
CAT	the item SKU — only when the payload contains exactly one item.

For CAT, the single-item rule matters: a batch CAT payload (many items) has no single object to name, so the ACK omits objectId. The other feed types always describe a single object (one order, one purchase order, one return), so their ACKs always carry it.

`missingSkus`

When a payload references SKUs that do not exist in RUC, the rejected ACK lists them under missingSkus. The schema permits it on PO, RMA and NO responses; the published rejection samples show it for PO and NO. CAT never emits missingSkus: CAT creates and updates items, so by definition nothing it references can be "missing".

A PO rejected for unknown SKUs:

<?xml version="1.0" encoding="UTF-8"?>
<apiResponse>
	<token>9d4c1a77e2b34f60a8c5d9021e6b73cc</token>
	<success>false</success>
	<feedType>PO</feedType>
	<errors>
		<error>The purchase order [ PO-0001 ] has been rejected! Request references SKUs that are not present in RUC.</error>
	</errors>
	<missingSkus>
		<sku>SKU9901</sku>
		<sku>SKU9902</sku>
	</missingSkus>
	<objectId>PO-0001</objectId>
</apiResponse>

The fix is to send a CAT feed for the missing SKUs first, then resend the PO, RMA or NO.

Integration flow — how inbound and outbound feeds and the REST services fit together.
XML API reference — every endpoint, request schema and ACK example, interactively.
Outbound XML API reference — every feed Paxon sends back to you (GR, OS, RS, ADJ, INV, IMS, ACK), with schemas and sample payloads.
Getting started — the platform overview and your first call.

XML API

How XML messaging works

Endpoint and authentication

The two-phase acknowledgement

CAT — catalogue / item master

PO — purchase order

RMA — return merchandise authorisation

NO — new order

Acknowledgements

Accepted

Rejected

The objectId contract

missingSkus

Next

The `objectId` contract

`missingSkus`