Bitcoin Web Services with vCO: Part 1, Coinbase

In the past I’ve done adhoc perl and php scripting scheduled via cron to do random duties.  I wanted to explore how easy it would be to replace one of them with vCO and turns out it’s dead simple.   Once I got the process down here in part 1, I did part 2 in literally only a few moments with only a few clicks to add a totally different service.   So lets get started..

Don’t know what Bitcoin is?   That’s ok, read here. And watch a video here.

Now that you know that, what are we doing?  Part 1 shows how to check the buy price for bit coin on a website called Coinbase.  I’ve found that to be the simplest way to purchase btc quickly with american dollars.   Part 2 shows how to modify the structure of this workflow to check an average current price across all exchanges on a website called Bitcoin Average.

Check out the API reference for Coinbase here.

Simplest REST operation I want to use is:
https://coinbase.com/api/v1/prices/buy?qty=1

Which currently gives the results:

Screen Shot 2013-10-24 at 2.03.56 PM

Alright great, we have the variables we want.   For this exercise I just want to access total.amount which is 197.01 at the time of this post.

For this new workflow I want to better implant modules than I have in the past.  So the workflow we run won’t actually do the alerting, but will call a different workflow ‘Pushover Alert’ for that.  Side benefit of this is I can keep the api key’s for pushover stored only in the one location.

The ‘Check Price’ script calls the rest operation, picks out the variable we want and formats the text part of the alert (if it’s needed).   ‘Decision’ simply forks based on if the value is under a certain about, for now I’m using 100 (wow it changed fast, I originally created this a few weeks ago before it jumped).  And lastly it either simply ends if above 100, or calls ‘Pushover Alert’ if over.

Screen Shot 2013-10-24 at 1.50.44 PM

The script for ‘Check Price’ is pretty straight forward and still using a bunch of system.log calls for troubleshooting:

Screen Shot 2013-10-24 at 2.14.03 PM

The first improvement I know I need to make is making the alert threshold a configureable variable but off the top I didn’t see a way to do it:

Screen Shot 2013-10-24 at 2.19.49 PM

As a test I changed the value to 250 to show an alert, and here’s what it looks like:

photo-2

There we have it, simple and useful.  The skeleton of this workflow can be duplicated to apply to other services very quickly as we’ll show next.    I may start posting an export of these workflows if there is any interest in it, let me know.

Tagged , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *