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_key
access_keycan be found on the API Token page
tonce
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.
signature
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}”
end
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 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
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
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
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 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
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
Mercury
bitcoinfundi-client-ruby (ruby)
About Us
Help & Support
Mailing List
Calculator
Price
YouTube
Blog
Email Us
API
Proof of Solvency
Privacy Policy
Terms & Conditions
30 Day Volume:
24 Hour Volume:
High:
Low:
Change: