Colorado Timberline APIA Practical Guide to Successful Integration

The Protocol


As stated previously, the CT API protocol is an XML payload over HTTP(S).

Protocol Basics

Prepare for strange requirements

The current major version of the API, 1.5, is a relic which has some baggage you will have to live with in the land of protocol-level integration. We have abstracted away this baggage as much as possible in the CT reference client, and so among other reasons recommend binding with that if possible.
Mostly you will see required XML that is useless to us on the backend and poor naming conventions or lack of consistency in naming conventions for node and attribute names. Theres also a lack of consistency regarding the allocation of tags vs. attributes. Again, all of this will go away in the 2.0 rev of the API, but for 1.5, protocol implementors will simply have to live with the existing schema.

No XSD’s for v1.5 Schemas

We do not have .xsd files describing what the XML payloads should look like, so please do not ask for them. You can almost certainly expect .xsd files for the 2.0 service though.

Opening Tag & Encoding

Each XML payload you send us should start out as

<?xml version="1.0" encoding="utf-8"?>

Do not URL Encode XML payloads, the payloads are unable to be parsed at that point and we will be unable to accept the order request as a consequence.