URI Prefix: /api/v1

Result Format: JSON

API List

Public/Private API

are two kinds of API interfaces for developers:

PUBLIC APIPRIVATE APIVerificationNo VerificationRequire VerificationApplication FrequencyNo Limitation600 requests / 5 minsPreparationsNo Preparation RequiredUse your API Token page to get access/secretkey

Applying a signature (Verification)

Before applying for Private API signature, you should prepare your access/secret_key. These materails could be found in the API Token page after registration.

All Private API users need the following 3 parameters when doing identity verification:


access_keycan be found on the  API Token page


tonceis the time stamp using positive integer, it repesents the number of millisecond from Unix epochThe time error between tonce and BitcoinFundi’s server could be limited to plus-minus 30 seconds. And, every value of tonce can only be used once.


signatureis generated aftersecret_keyon the  API Token page

Verification Steps

The generation process of signature is simple. First, the application should be transfer into a character string. Then use this character string to do HMAC-SHA256 calculation:

hash = HMAC-SHA256(payload, secret_key).to_hex

payload is representing the applied character string, it could be fomulate by using HTTP method. The application address and parameter is listed below:

# Canonical_verb request method, such as GET

# Canonical_uri request address, for example / api / v1 / markets

# Canonical_query request parameter string parameters include access_key & connected together and tonce

# Parameters must be listed in alphabetical order, for example access_key = xxx & foo = bar & tonce = 123456789


# Finally the three string by ‘|’ characters to link up looks like this:

# GET | / api / v1 / markets | access_key = xxx & foo = bar & tonce = 123456789

def payload

“# {Canonical_verb} | # {canonical_uri} | # {canonical_query}”


Assume thesecret key isyyy, then using HMAC-SHA256 algorithm to calculate thepayload mentioned above, the result is(use hex to illustrate):

payload = ‘GET|/api/v1/markets|access_key=xxx&foo;=bar&tonce;=123456789’

hash = HMAC-SHA256(payload, ‘yyy’).to_hex

# e324059be4491ed8e528aa7b8735af1e96547fbec96db962d51feb7bf1b64dee

Now, we could make application by using this signature(use curl for example):

curl -X GET ‘https://bitcoinfundi.com/api/v1/markets?access_key=xxx&foo;=bar&tonce;=123456789&signature;=e324059be4491ed8e528aa7b8735af1e96547fbec96db962d51feb7bf1b64dee’

Return result

If API call failed, the return will use HTTP status code. Also, the return include detail error information showing JSON data. For example:

{“error”: {“code”: CODE, “message”: MESSAGE}}

All the errors have the same format according to the above sentence, the only differences arecode andmessage. Code is the custom error defined by BitcoinFundi, it illustrates the category of the error. Message is detail error information.

For complete API application, BitcoinFundi will return 200 for JSON data.

Data Type


Market Market include all the market information, for example: BTC/USD.


“at”: 1398410899, // in seconds timestamp

“ticker”: {

“buy”: “3000.0”, // current bid price

“sell”: “3100.0”, // current selling price

“low”: “3000.0”, // in the last 24 hours of the lowest

“high”: “3000.0”, // in the last 24 hours the highest price

“last”: “3000.0”, // the last traded price

“vol”: “0.11” // Total volume within the last 24 hours




Member include the information of a user:


“sn”: unique number “PEA5TFFOGQHTIO”, // user

“name”: “foo”, // Username

“email”: “foo@bitcoinfundi.com”, // user mail address

“activated”: true, // whether the user has activated

“accounts”: [// all user account information [see Account]

{ “currency”: “usd”, “balance”: “100243840.0”, “locked”: “0.0”},

{ “currency”: “btc”, “balance”: “99999708.26”, “locked”: “210.8”}




Account includes all the assets user has:


“currency”: “usd”, // currency accounts such as usd or btc

“balance”: “100243840.0”, // account balance does not include the freezing of funds

“locked”: “0.0” // account the freezing of funds



Order includes the information of every single order.


“id”: 7, // a unique Order ID

“side”: “sell”, // Buy / Sell representatives pay / sell orders

“price”: “3100.0”, // bid

“avg_price”: “3101.2”, // Average price

“state”: “wait”, the current status of orders // [wait, done, cancel]

// Wait show orders are pending on the market

// Is an active order

// At this order may not yet part of the transaction or auction

// Done on behalf of the order has been completely deal

// Cancel orders have been revoked on behalf of

market “btcusd”, // order to participate: “market”

“created_at”: “2014-04-18T02: 02: 33Z”, // Order Time ISO8601 format

“volume”: “100.0”, // Buy / Sell Number

“remaining_volume”: “89.8”, // yet the number of transactions is always less than or equal volume remaining_volume

// Becomes 0 when the transaction is fully in line

“executed_volume”: “10.2”, // is the number of transactions

// Volume = remaining_volume + executed_volume

“trades_count”: 1, number of transactions integer values ​​// Order

// 0 Unsold order to have a turnover of orders 1

// With this field you can determine whether the order is part of the state deal

“trades”: [// detailed transaction records See Trade Order

// Note: Only certain return detailed order data will be included in the API data Trade


“id”: 2,

“price”: “3100.0”,

“volume”: “10.2”,

“market”: “btcusd”,

“created_at”: “2014-04-18T02: 04: 49Z”,

“side”: “sell”





Trade Trade includes every transaction made by order.


“id”: 2, unique transaction ID //

“price”: “3100.0”, // price

“volume”: “10.2”, // number of transactions

“market”: “btcusd”, // transaction belongs market

“created_at”: “2014-04-18T02: 04: 49Z”, // turnover time

“order_id”: 101, // buy / sell to buy or sell

“side”: “sell” // transaction to your Order ID



OrderBook includes the orders on the market.


“asks”: […], // list of sell orders

“bids”: […] // list of all buy orders


Dos and don’ts

Cancel order

Cancel order andcancel all the orders  are asynchronous operations, API return complete only means cancel application has been submitted, it doesn’t mean your order has been canceled. If you have orders which haven’t been processed or the cancel queue is busy, your cancel application will delay. API returns the canceled order, the return order may not be conceled. Your code should not rely on API retrun result. It should get the latest status by using “order inquiry interface”.

Open Source Projects/Libraries/Tools that utilise the BitcoinFundi API


bitcoinfundi-client-ruby (ruby)

About Us

Help & Support

Mailing List







Email Us


Proof of Solvency

Privacy Policy

Terms & Conditions

30 Day Volume:

24 Hour Volume: