Wallet API is a service that provides the ability to receive and send payments using API requests. Funds on the wallet are fully controlled by the service, we recommend storing only operational stock for payments. For large amounts and long-term storage of cryptocurrencies, use cold storages that are fully controlled by you.
The wallets service can be used to accept payments on website, similar to payment forwarding services. The difference is that the transfer of funds does not occur and when a payment is received at the generated address, the wallet balance is replenished.
Each wallet can have an unlimited number of replenishment addresses, which allows using one wallet for the entire set of addresses issued to users . Addresses have an unlimited period of validity. Each address can have an individual link for notification of received payments or use the common link specified for the wallet in case the individual callback link is not specified.
When creating the wallet, it is recommended to set a password and use it requests with HMAC signature.
For all supported cryptocurrencies, APIs are available for Mainnet, Testnet, and the Tor network. For testnet networks available coins faucet and explorers.
Mainnet URL: https://api.bitaps.com/{currency}/v1/For API, restrictions of requests by IP addresses apply. Standard limit 60 requests within 5 seconds for a single IP address. If you need more requests, then you need to purchase an API token. For questions about obtaining a token API, contact support@bitaps.com. If the limit is exceeded, a page with the status 429 to many requests is given in response to the request. If an error is received, you should wait for the time limit to be restored, otherwise the IP address will be blocked for 3 minutes. The current status of the limits can be found in the response headers Ratelimit-Remaining and Ratelimit-Reset .
The service charges a flat rate commission from each payment received or sent. The miners commission paid when sending the payment is included in the service fee.
Commissions:
| Currency | Service fee | Additional receiver | Min. TX Value |
|---|---|---|---|
| Bitcoin incoming | 0.00005 BTC | > 0.00000546 BTC + Service fee | |
| Bitcoin with commitment outgoing | 0.00005 BTC | > 0.00000546 BTC + Service fee | |
| Bitcoin instant outgoing (mempool fee rate < 75 s/vByte) | 0.00045 BTC | 0.00001 BTC | |
| Bitcoin instant outgoing (mempool fee rate < 160 s/vByte) | 0.00045 BTC | 0.00001 BTC | |
| Bitcoin instant outgoing ( mempool fee rate > 160 s/vByte) | 0.00060 BTC | 0.00001 BTC | |
| Bitcoin cash | 0.0004 BCH | 0.00003 BCH | > 0.00000546 BCH + Service fee |
| Ethereum | 0.004 ETH | > 0.001 ETH + Service fee | |
| Litecoin | 0.0004 LTC | 0.00003 LTC | > 0.00000546 LTC + Service fee |
When creating a wallet, it is recommended to specify a password with which all requests for transactions with the wallet will be signed by the HMAC. Optionally, a link for incoming / outgoing payment notifications can be specified.
Request returns the ID of the created wallet. An example of the ID of the created wallet: BTCv5QsMiXRDeNjx7RSWyQAdLS4wxniJ6L57rBaSWqBW4tW3fTPmt . If during the creation of the wallet a password was set, API calls for such a wallet should be signed with HMAC signature. If the wallet password was not set, we draw your attention to the fact that you should keep the wallet ID secret, the use of a wallet that is not password protected is not recommended.
Create HMAC signature:
key = double_sha256(wallet_id + password)
msg = wallet_id + nonce
HMAC_signature = HMAC(key, msg)
Nonce and HMAC_signature should be in request headers.
Access-Nonce: nonce
Access-Signature: HMAC_signature
Create a payment address for the wallet. Optionally, an individual callback link can be specified for the address. In case the link is not specified, the callback specified for the wallet will be used. If the wallet callback was also not specified, no notifications will be sent.
Description of the payment notification handler with the description of the incoming POST parameters. Payment notifications are received when the following events occur.:
For example, if a payment address is created with 2 confirmations, it will receive the following notifications: unconfirmed, pending [1/2], confirmed.
The logic for processing payment notifications should be as follows. Each payment address corresponds to a confirmed and unconfirmed balance. N - the number of required confirmations.
Processing incoming notifications:
Payment notifications have logic to protect against failure. As a confirmation that the notification has been received, the service expects to receive a response in the form of a code invoice code in response body for each http request.
In case no correct answer, notifications will be repeated with each new block within 24 hours. IP addresses from which notifications are sent are available via dns request to the domain name callback.bitaps.com. If the answer is not successful, repeated attempts are made from different IP addresses. To stop sending notifications, notification handler should reply with correct response to any notification with the number of payment confirmations greater than or equal to the specified value when generating a payment address.
TorTor notifications supported
Callback log for payment address. Authorization required by request headers Payment-Code or Access-Token.
Callback logs for payment transaction hash. Authorization required by request headers Payment-Code or Access-Token.