QueruBtce

KISS BTC-e and now wex.nz API Access from Ruby.

• It supports wex.nz, former BTC-E.
• 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).
• Fast and lightweight: A small module.
• I did used every other gem and still needing this one.

• Not much abstraction, you should know BTC-e API.
• Its new, so I don't know a lot of people using it in production.

Gemfile:

gem 'queru_btce'

Execute:

$ bundle

Or install:

$ gem install queru-btce

This gem provides class methods for all public/private API methods offered by BTC-e. Responses are objects (dot methods or hash access) and any errors are raised as exception, your program can handle it.

• BTC-e Trade API Documentation
• BTC-e Public API Documentation

In BTC-e API some methods are CamelCase. In this gem those method must be called in snake_case format. For example TradeHistory becomes QueruBtce.trade_history.

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

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}"

All the described at BTC-e documentation:

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

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

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

Nounce 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 real problem because API can dump you out when 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.

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

To Brock Harris, I did started from his gem.