Skip to main content

Troubleshooting

A request is rejected before the operation runs​

Check the transport first:

  • use exactly /veloconnect/v1;
  • send POST bodies as raw XML with Content-Type: application/xml;
  • do not wrap the XML in JSON or form data;
  • remove a byte-order mark or text before the XML declaration;
  • for GET, include a non-empty RequestName and BuyersID;
  • for POST, make the XML root name end in Request.

The server removes the Request suffix to select the operation. A misspelled or unsupported root therefore cannot be dispatched.

Authentication fails​

Confirm that the BuyersID and password were issued as a pair. Remove leading or trailing whitespace from the buyer identifier. For POST, place the password inside vct:Credential/vct:Password. For GET, prefer the x-api-key header.

Never paste credentials into tickets, logs, screenshots, or example files. When asking for support, share the time of the request, operation name, test flag, response code, and a redacted request.

XML/XSD validation fails​

Veloconnect schemas are order-sensitive. XML containing all the right elements can still be invalid when they are in the wrong order.

Verify that:

  • the root namespace matches the operation and protocol version;
  • vct, cac, and cbc prefixes point to the expected namespaces;
  • required values are present and not empty;
  • booleans are true or false;
  • dates and date-times use the schema-defined ISO format;
  • quantities contain the expected unit attribute;
  • the document is well-formed XML and special characters are escaped.

Validate locally against the applicable Veloconnect XSD before sending the request. Start from a working minimal request and add optional fields in schema order.

The response is JSON instead of XML​

HTTP 400 with a JSON object containing status, type, and faults indicates that request or generated response validation failed. Log the diagnostic after redacting identifiers, then correct the XML or contact support if the reported failure concerns the generated response.

For ordinary Veloconnect errors, expect an XML response and inspect its ResponseCode even when the HTTP status is 200.

A transaction cannot be found​

Use the TransactionID returned by the immediately preceding create or transmit response. Do not invent, shorten, or reuse an ID from another buyer. Also verify that:

  • the same BuyersID is used throughout the flow;
  • IsTest has not changed;
  • the transaction has not already been closed;
  • the operation belongs to that transaction type.

For text searches, set DoNotClose=true until the final page when multiple SearchResultRequest calls are required.

A query returns no documents​

An empty result is valid. Check that the document IDs belong to the buyer and that the complete date range was supplied. FromDate and ThruDate should be used together. Broaden the range carefully or query without filters to confirm whether documents are available.

A transmitted batch is accepted but lines fail​

Creation of a stock or sale transmission is not the final processing result. Save its TransactionID and call the matching status operation with StartIndex and Count. Continue paging until every line has been inspected.

Safe retry rules​

Read-only profile, item, search-result, status, and document queries can usually be retried after a transient transport failure. Be more careful with create, finish, stock, and sale requests: first query the known transaction state to avoid creating or finalising the same business operation twice.