Requests and responses

Every request is processed in the same broad order:

1. authenticate the password or API key;
2. identify and verify the BuyersID;
3. determine the requested operation;
4. validate POST bodies against the matching Veloconnect XSD;
5. verify transaction and business identifiers;
6. perform the operation and build an XML response.

For POST requests, use the request element shown in the tables as the root element. For GET requests, use that name as the RequestName value. The response normally has the corresponding Response suffix.

Discovery and product information

Request	What it does	Input needed	Successful response
GetProfileRequest	Discovers server capabilities and bindings.	Authentication and BuyersID.	GetProfileResponse with implemented operations, bindings, properties, and known query limitations.
GetClassificationSchemeRequest	Retrieves the product classification tree.	Authentication and BuyersID.	GetClassificationSchemeResponse with classification groups and identifiers.
GetItemDetailsRequest	Retrieves one product.	A seller item identifier in cac:SellersItemIdentification/cac:ID.	GetItemDetailsResponse with the matching item data available to the buyer.
GetItemDetailsListRequest	Retrieves several products and their requested quantities.	One or more request entries containing an item identifier and quantity.	GetItemDetailsListResponse with a result entry per processed item.

An authenticated request can still return no product data when the identifier is unknown, is not part of the buyer's assortment, or is no longer available. Clients must therefore check the response code and returned entries instead of assuming that authentication implies a match.

Item details example

<?xml version="1.0" encoding="UTF-8"?>
<GetItemDetailsRequest
  xmlns="urn:veloconnect:order-1.1"
  xmlns:vct="urn:veloconnect:transaction-1.0"
  xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-1.0">
  <vct:BuyersID>YOUR_BUYERS_ID</vct:BuyersID>
  <vct:Credential>
    <vct:Password>YOUR_PASSWORD</vct:Password>
  </vct:Credential>
  <vct:IsTest>true</vct:IsTest>
  <cac:SellersItemIdentification>
    <cac:ID>SELLER_ITEM_ID</cac:ID>
  </cac:SellersItemIdentification>
</GetItemDetailsRequest>

For the GET binding, pass SellersItemIdentification=SELLER_ITEM_ID.

Text search

Text search is a two-step transaction:

Request	What it does	Input needed	Successful response
CreateTextSearchRequest	Creates a snapshot for a search phrase.	SearchString; an empty value requests the unfiltered catalogue.	CreateTextSearchResponse containing TransactionID and TotalCount.
SearchResultRequest	Reads a page from that snapshot.	Returned TransactionID, StartIndex, Count, ResultFormat, and optionally DoNotClose.	SearchResultResponse with paging information and results in the requested format.

Supported ResultFormat values are:

• COUNT: return counts rather than product records;
• ITEM_DETAIL: return detailed product information;
• ITEM_TYPE: return item-type information;
• ID_ONLY: return identifiers only.

The generated TransactionID is required for every SearchResultRequest and must be passed back unchanged. Use non-negative paging values. Set DoNotClose=true when another page will follow; otherwise the server may close the search transaction after serving the result.

Orders

The order transaction has a lifecycle. Keep the TransactionID returned by CreateOrderResponse and reuse it for all later steps.

Request	What it does	Input needed	Successful response
CreateOrderRequest	Opens an order transaction and checks the initial lines.	Valid order lines with seller item IDs and quantities.	CreateOrderResponse with a new TransactionID, line results, availability, and pricing where available.
UpdateOrderRequest	Changes an open order transaction.	The same BuyersID, its TransactionID, and the revised lines.	UpdateOrderResponse with the recalculated order state.
ViewOrderRequest	Reads the current open order.	TransactionID.	ViewOrderResponse with the current header and lines.
FinishOrderRequest	Finalises the open order.	TransactionID and a transaction that is in a finishable state.	FinishOrderResponse with the final processing result and identifiers.

For successful processing, every item must be identifiable, quantities must be valid, and the transaction must belong to the authenticated buyer. Do not send updates after finishing an order.

Transaction control

Request	What it does	Input needed	Successful response
GetStatusRequest	Reads the state of one transaction, or the available transaction status for the buyer.	Authentication and, when known, TransactionID.	GetStatusResponse containing one or more transaction status records.
RollbackRequest	Requests rollback of a transaction.	A valid, rollback-capable TransactionID.	RollbackResponse with the transaction result.

Rollback is state-dependent. A syntactically valid request can still be rejected when the transaction is already completed or cannot be rolled back.

Order confirmations, delivery notes, and invoices

Query operations return document headers; details operations return the lines for selected document identifiers.

Request	Filters accepted	Successful response
OrderConfirmationQueryRequest	OrderConfirmationID, OrderID, or a complete FromDate/ThruDate range.	Matching order-confirmation headers.
OrderConfirmationDetailsRequest	One or more OrderConfirmationID values.	Header and line details for those confirmations.
DeliveryNoteQueryRequest	OrderConfirmationID, OrderID, or a complete date range.	Matching delivery-note headers.
DeliveryNoteDetailsRequest	One or more DeliveryNoteID values.	Header and line details for those delivery notes.
InvoiceInformationQueryRequest	DeliveryNoteID, OrderConfirmationID, OrderID, or a complete date range.	Matching invoice headers.
InvoiceInformationDetailsRequest	One or more InvoiceID values.	Header and line details for those invoices.

Send both FromDate and ThruDate when filtering by date. An absent or incomplete date range is not treated as a valid bounded period. Document IDs must belong to the authenticated buyer. DeliveryNoteQuery does not support every possible standard filter; consult GetProfileResponse for advertised limitations.

Stock and sales transmission

These operations use XML POST and are asynchronous transaction-style flows.

Request	What it does	Input needed	Successful response
StockTransmitB2BRequest	Sends B2B stock records.	Valid stock lines, item identifiers, quantities, and transmission frequency where applicable.	StockTransmitB2BResponse with a new TransactionID and acceptance status.
GetItemStatusStockTransmitB2BRequest	Reads per-item processing results for a B2B stock transmission.	TransactionID, StartIndex, and Count.	A paged item-status response.
StockTransmitB2CRequest	Sends B2C stock/location records.	Valid stock lines plus the location data required by the schema.	StockTransmitB2CResponse with a new TransactionID and acceptance status.
GetItemStatusStockTransmitB2CRequest	Reads per-item processing results for a B2C stock transmission.	TransactionID, StartIndex, and Count.	A paged item-status response.
SaleTransmitB2BRequest	Sends B2B sale records.	Sale date, sale type, item IDs, quantities, and schema-required line information.	SaleTransmitB2BResponse with a new TransactionID and acceptance status.
GetStatusSaleTransmitB2BRequest	Reads per-line processing results for a sale transmission.	TransactionID, StartIndex, and Count.	A paged sale-status response.

An accepted transmission only confirms that a transaction was created. Poll the corresponding status operation and inspect every returned line to decide whether all records were processed successfully.

Understanding responses

A normal XML response contains at least the buyer context and a Veloconnect ResponseCode. Depending on the operation it can also contain ResponseMessage, TransactionID, StatusCode, IsTest, paging information, and business data.

<?xml version="1.0" encoding="UTF-8"?>
<OperationResponse xmlns:vct="urn:veloconnect:transaction-1.0">
  <vct:BuyersID>YOUR_BUYERS_ID</vct:BuyersID>
  <vct:ResponseCode>200</vct:ResponseCode>
  <vct:TransactionID>RETURNED_TRANSACTION_ID</vct:TransactionID>
  <vct:IsTest>true</vct:IsTest>
  <!-- operation-specific data -->
</OperationResponse>

The example is an abbreviated response shape, not an XSD-valid replacement for a concrete operation response.

Protocol response codes

Code	Meaning	Client action
200	Request processed successfully.	Continue the flow and inspect operation-specific results.
400	General request error.	Check required fields and values.
404	Request is not supported.	Refresh capabilities with GetProfile.
405	Request is syntactically incorrect.	Validate XML, namespaces, element order, or RequestName.
406	Request is out of date.	Recreate the request from current data.
410	Unknown BuyersID.	Use the identifier issued for these credentials.
411	Authentication failed.	Verify the password without logging or sharing it.
415	Unknown seller identifier.	Verify the seller context advertised by the profile.
420	Unknown TransactionID.	Use the ID returned by the create/transmit response.
421	No transaction instance is available.	Start the required transaction first.
430	Operation is not valid in the current transaction state.	Correct the transaction sequence.
435	Test mode changed during a transaction.	Reuse the original IsTest value.
500	Internal server error.	Retry safely; contact support if it persists.

Do not rely on the HTTP status alone. Protocol-level errors are commonly returned as XML over HTTP 200. Conversely, request or response schema failures can result in HTTP 400 with a JSON diagnostic object. A robust client checks, in order: HTTP status, content type, XML parseability, ResponseCode, and the operation-specific status and line results.