queru-btce

KISS BTC-e API Access from Ruby.

Pros:

  • No config file and no framework dependency.
  • No weird abstractions, you can follow BTC-e API specs.
  • Returns an object, keys are methods.
  • Really few error abstraction, exceptions are raised.
  • Nounce is enforced, I don't expect damm nounce error.
  • Tests for the public API (rake test).

Cons:

  • Not much abstraction, you should know BTC-e API.
  • Its in BETA status. Not production tested until now.

Installation

Gemfile:

gem 'queru_btce'

Execute:

$ bundle

Or install:

$ gem install queru-btce

Usage

This gem provides class methods for all public/private API methods offered by BTC-e. Responses are hashes and any errors are raised as exception, your program can handle it.

You can call any BTC-e API method this way:

Public API example:

info = QueruBtce.info
puts info.server_time

btc_usd = QueruBtce.ticker(:btc_usd)
puts btc_usd.ask
puts btc_usd.bid

QueruBtce.ticker(:btc_usd).btc_usd.last
mytickers = QueruBtce.ticker(:btc_usd, :eth_usd, :ltc_usd)
puts "BTC: #{mytickers.btc_usd.last}"
puts "ETH: #{mytickers.eth_usd.last}"
puts "LTC: #{mytickers.ltc_usd.last}"

Public API methods:

All the described at BTC-e documentation:

QueruBtce.info
QueruBtce.ticker
QueruBtce.depth
QueruBtce.trades

Private API:

QueruBtce.credentials key: 'mykey', secret: 'mysecret'
my_info = QueruBtce.get_info
puts my_info.return.funds.btc

orders = QueruBtce.active_orders pair: :btc_usd
puts 'I have open orders' if orders.return

Trade API methods:

All the described at BTC-e documentation. Parameters are passed as hash, for example:

QueruBtce.trans_history from: 0, count: 100, order: 'ASC'

The list is:

QueruBtce.get_info
QueruBtce.trans_history
QueruBtce.trade_history
QueruBtce.active_orders
QueruBtce.trade
QueruBtce.cancel_order

Tips:

Nounce error:

Nonce is param required by BTC-e trade api, is just an integer but the current one should be greater than the last one. I guess they require it to ensure your transactions are received in a known order, sequentially.

This gem always send a timestamp as nounce, ensuring its greater than the last one, so calls are delayed a second between. Not a problem cause API can dump you if you try to ask faster.

But if you are calling the API from more than one process, there's no locking mechanism in gem (maybe in the future) and you need to implement a lock to prevent making two calls at once. A cache key, or distributed message can do the work, even a semaphore file locking.

It remains at your side by the moment.

Contributing

Pull requests, issues and comments are welcome the most of the days.

Thanks

To Brock Harris, I did started from his gem.