Last modified: Fri Sep 20 2019 11:21:30 GMT+0000 (Coordinated Universal Time)

How to publish bulk inventory for multiple hotels

Do you manage a system that represents many hotels or properties? In this tutorial, you will learn how you might integrate with Winding Tree ecosystem with the existing tooling.

Requirements

Step by step

Winding Tree's goal is proper data ownership. That is why every ORG.ID can be manipulated only by the holder of it's owner's Ethereum wallet.

There are multiple ways of managing more than one hotel in a single system. We will try to give you some advice and recommendations here for such setup.

Write API setup

Write API is ready to handle multiple hotels at once. It is also capable of working with multiple separate accounts tied to multiple separate Ethereum wallets.

We recommend to set up your system in a way where one Ethereum wallet = one Write API account = one hotel. This is the most secure and most performant solution. It may be a little bit challenging to distribute ETH to all of these wallets but you can for example pre-allocate wallets etc.

If multiple hotels would share a wallet, it would mean that they will be effectively owned by the same entity. It would also mean that you would not be able to update them simultaneously due to limitations in transaction concurrency on Ethereum.

In any case, it would be wise to run Write API on-premise and not expose it to the public internet.

Hosting data on your own infrastructure

There is quite a big chance that when you are managing many hotels, you already have some system in place, maybe even a public API that your consumer facing applications are using.

You can expose an existing API in your ORG.ID. However, you are relying on some support of that API from the business partners. There's a chance that no one would be able to consume your proprietary API.

For convenience or testing, you can expose the data in Winding Tree Data Model format. In such setup, it of course does not make sense to publish all of the data via Write API.

For such cases, the Write API offers a shorthand method for registering hotels by submitting only the entrypoint URI and it's contents hash that gets stored on blockchain. The initial setup is the same as in the case with full-fledged data upload — you need to create an account in Write API. However, you don't need to specify any uploaders in this case.

{
  "wallet": {"version":3,"id":"7fe84016-4686-4622-97c9-dc7b47f5f5c6","crypto":{"ciphertext":"ef9dcce915eeb0c4f7aa2bb16b9ae6ce5a4444b4ed8be45d94e6b7fe7f4f9b47","cipherparams":{"iv":"31b12ef1d308ea1edacc4ab00de80d55"},"cipher":"aes-128-ctr","kdf":"scrypt","kdfparams":{"dklen":32,"salt":"d06ccd5d9c5d75e1a66a81d2076628f5716a3161ca204d92d04a42c057562541","n":8192,"r":8,"p":1},"mac":"2c30bc373c19c5b41385b85ffde14b9ea9f0f609c7812a10fdcb0a565034d9db"}},
  "uploaders": {}
}
$ curl -X POST localhost:8000/accounts \
  -H 'Content-Type: application/json' \
  --data @account.json

# accountId and accessKey are generated and will be different every time
{"accountId":"aa43edaf8266e8f8","accessKey":"usgq6tSBW+wDYA/MBF367HnNp4tGKaCTRPy3JHPEqJmFBuxq1sA7UhFOpuV80ngC"}

Then, you prepare the data document, which in this case, is much shorter. We will save this file under hotelWithoutData.json. The orgJsonUri value should be pointing to your own service which responds with the data entrypoint for given hotel's ORG.ID. The also mandatory hash property should hold a keccak256 hash of the data entrypoint contents. The hash serves as a way of checking the integrity of your data. Do not forget to update the hash whenever you change the ORG.JSON!

{
  "orgJsonUri": "https://my-custom-api.example.com/hotel-12345",
  "hash": "0xea937104edca4af1f37e47808a5667173e83cc6033e0cf6e6a3c9f7c102b8beb"
}

And then with a simple request with that data, we register the hotel in Winding Tree ecosystem.

$ curl -X POST https://madrid-write-api.windingtree.com/hotels \
  -H 'Content-Type: application/json' \
  -H 'X-Access-Key: write-api-account-access-key' \
  -H 'X-Wallet-Password: ethereum-wallet-password' \
  --data @hotelWithoutData.json

In the response, you will get an Ethereum address where your hotel's ORG.ID is registered. That address belongs only to the holder of the used Ethereum wallet and noone else can modify the data stored there.

{"address":"0xA603FF7EA9A1B81FB45EF6AeC92A323a88211f40"}

In order to update the orgJsonUri and its hash, you just issue a PATCH request with the same data structure.

$ curl -X PATCH https://madrid-write-api.windingtree.com/hotels/0xA603FF7EA9A1B81FB45EF6AeC92A323a88211f40 \
  -H 'Content-Type: application/json' \
  -H 'X-Access-Key: write-api-account-access-key' \
  -H 'X-Wallet-Password: ethereum-wallet-password' \
  --data @hotelWithoutData.json

Where to next