Last modified: Mon Nov 04 2019 16:15:12 GMT+0000 (Coordinated Universal Time)


Another layer consists of a set of REST APIs which Winding Tree maintains reference open-source implementations of. You can use them for convenient access to platform data in the runtime environments or you can run them by yourself. We have separated the functionality into a few groups because the requirements are different for various use cases.

While we consider our implementation of the API as reference or sample ones, the more important are the API definitions. We of course allow anyone to build any tool they need, but we would like to ask you to keep the API definitions of the same APIs as uniform as possible, so it's easy to switch between implementations. This is the key component of a success of a fully distributed system such as Winding Tree.


For reading the data, we provide a Read API which is a thin API abstracting you from any blockchain or off-chain storage related stuff. It behaves like any other REST API and it's the easiest way of getting the data into your system. It is currently limited to hotel and airline data that conform to the Winding Tree Data Model.

For more advanced use cases, we also provide a sample implementation of a Search API which can track and cache all available data (currently limited to hotels) in Winding Tree platform and gives its users a REST API for searching for inventory by multiple criteria, such as location.


We recommend to update your data on blockchain directly for security reasons - arguably the best solution is to handle your off-chain data internally on a mutable HTTPS endpoint and communicate with the blockchain only once when you are creating your ORG.ID.

If you, however, want to write the data via a REST API, you would use the Write API. It is intended as an on-premise installation and you can read more about it here and here. The main challenge is the management of private keys that can potentially be tied to a significant amount of funds in cryptotokens. That's why we recommend a careful approach to this API.

Part of distributing the data is surely a way of letting the data consumers know that something has changed. To speed the process up, we provide a sample implementation of Notification API which works as a message broker between data producers and data consumers. Producers can publish notifications about their updates there and consumers can subscribe to them.

This might seem like a centralized service, but every data producer is free to choose or even run an instance of Notification API. The used service is declared in the data stored in the ecosystem - so it is de facto decentralized as well.


Our current solution for booking consists of a description of a Booking protocol and API. Again, URI of this API should be provided with the data itself, making it a decentralized venture.

The Booking protocol is tied to the Winding Tree Data Model, so it probably cannot universally be reused as a generic booking interface.

Where to next