Ephemeral Exchange

Sometime you need to exchange transient data between platforms, but they don't talk to each other very well. For example you could be launching a webapp with some data generated from Excel, but you want to get feedback data back into Excel again. You could use a database, or push/pull solutions, but it can be complex to set up, and the authentication is often difficult to get right.

What is Ephemeral Exchange

It's a JSON API to exchange ephemeral data that doesn't need each platform to authenticate, but relies on using keys that are known by each collaboration party, and issued by the API. Apps knowing the item id, and appropriately authorized access keys can use them to retrieve data written by an entirely different platform (even using a web browser)

Hosted or open source

The code is open source, but I'm also providing a hosted solution on Google Cloud Platform. All you need to do is register, get a boss key, and you are ready to go. The hosted solution supports CORS and of course JSONP too.


The hosted solution is of course public, but the data is transient - It only allows data to persist for a short period of time. There is a lot of security built into the access solution, some of which is described below. The key thing is that permissions are on a single item level, so you can allow an app to access one item in your store, but not another.

Access Keys

Keys are used to identify yourself and to enable you to access the exchange. They expire after some period of your choosing, and are associated with a particular registered account, and different kinds of keys can do different things. 

Boss key

It looks like this, and you can use it to generate writer and reader keys for your account. You might want to generate multiple keys so you could give them different expiry times and use different keys to allow access to specific items or types of items.

Here's an example of generating 2 reader keys that will expire after 2 days, plus the response


{ "type": "reader", "plan": "a", "lockValue": "", "ok": true, "validtill": "Thu, 15 Dec 2016 13:38:52 GMT", "keys": [ "rak-4ru-2k19ubf138pb", "rak-4pv-2x19lbf1338b" ], "accountId": "f32" }

Reader key

Looks like this, and you can generate them to share with apps and others who you are allowing to read  data items.

This example is using a write key to write some data, and is also assigning some keys that can read that data (Note that in these example I'm using GET to write small amounts of data. This makes it possible to use the Browser or other platforms that don't allow POST, but normally data is written with POST)


{ "writer": "wak-h4l-b1235bf5f3d6", "ok": true, "id": "3qik236b1gl9hdsaf", "plan": "a", "accountId": "f32", "readers": [ "rak-4ru-2k19ubf138pb", "rak-3fm-2esgkbf13d76" ], "lifetime": 3600, "code": 201 }

and here is one of these keys issuing a read request for that item


{ "reader": "rak-4ru-2k19ubf138pb", "ok": true, "id": "3qik236b1gl9hdsaf", "accountId": "f32", "value": "goodreaders", "code": 200, "modified": 1481636336955 }

Writer key

Looks like this, and you can generate them to share with apps and others who you are allowing to update data items.


This example an item is being written, allowing another write key to update it.


{ "writer": "wak-h4l-b1235bf5f3d6", "ok": true, "id": "3qzj2i16s3gbzvlzf", "plan": "a", "accountId": "f32", "writers": [ "wak-z4r-b1231bf5f3g6", "wak-d4s-b123jne5f3h6", "wak-34a-b123pbe5f3k6", "wak-34p-b123cpf5f3v6" ], "lifetime": 3600, "code": 201 }

and here is the item being updated by that other write key


{ "writer": "wak-z4r-b1231bf5f3g6", "ok": true, "id": "3qzj2i16s3gbzvlzf", "plan": "a", "accountId": "f32", "lifetime": 3600, "modified": 1481636337242, "code": 201 }


If you want, you can  put a lock on a key. This is essentially a password that user must know before the key is usable. You lock a key when generated with lock=somepassphrase, and then the key cannot be used except with unlock=thepassphrase

Item keys

When an item is written to the store it generates a unique id, which is associated with your account. You can also specify a lifetime for that item, after which it expires. Every item has a default lifetime of 30 minutes. Before an item can be accessed, you need the item id, along with the access key that created it plus the lock if there is one, and also the key has to be one that is associated with your account. The only key that can read an item by default is the one that created it. However, you can add a list of reader keys that can access an item, or writer keys that can update that item. A public item key looks like this.


All the data is encrypted as it is written to the store.

For more like this, see Google Apps Scripts snippets. Why not join our forum, follow the blog or follow me on twitter to ensure you get updates when they are available.