<p>The API blockchain.info provides for the address details does a ton of processing at it's backend (by accessing the blockchain for which they must have maintained a separate db for quick fetches). As far as the transaction fee is concerned, it can be calculated by finding the difference in the inputs and outputs of a transaction. This is somewhat tricky because the vin (input) for any transaction points to the output of another transaction. But the point being you can find the difference and the transaction fee.</p>

<p>I suggest you query the blockchain using the core Bitcoin API and maintain your own database as per your convenience. The blockchain.info API is kind of a dependency for the app and if their server goes down, so does your app. So maintaining a custom formatted data on your side is a good way to go and also ensures responsiveness.</p>

CC BY-SA 3.0
2016-11-02T14:53:47.083Z
2016-11-02T14:53:47.083Z
Shabahat M. Ayubi
<p>I'm building an app to display information pertaining to individual Bitcoin addresses.  </p>

<p>I've been using the blockchain.info API to get data regarding the <code>final_balance</code>, <code>total_received</code>, and <code>total_sent</code>.  </p>

<p>But I'm having a little trouble figuring out how to retrieve data on transaction fees.   </p>

<p>Looking at the json when querying an address (<a href="https://blockchain.info/address/1CK6KHY6MHgYvmRQ4PAafKYDrg1ejbH1cE?format=json" rel="nofollow noreferrer">for example 1CK6KHY6MHgYvmRQ4PAafKYDrg1ejbH1cE</a>) I'm assuming I would need to iterate through the hash of transactions it returns, and use the hash of the transaction with the value "result" > 0?  </p>

<p>I'm just not certain how to differentiate between spending and receiving when looking at the json.</p>

CC BY-SA 3.0
2016-11-02T14:46:09.370Z
that's a hard address to consider, why don't you look at one that has less transactions, like this one https://blockchain.info/address/1AdCDBz2VmhUZDyDbibMo2QGGSjt93zbRv
smatthewenglish
<transactions><api><transaction-fees>
Calculating total outgoing transaction fees associated with a single address?
ColdCrush
# Calculating total outgoing transaction fees associated with a single address?

(Asked by: username_0 on 2016-11-01)

I'm building an app to display information pertaining to individual Bitcoin addresses.

I've been using the blockchain.info API to get data regarding the `final_balance`, `total_received`, and `total_sent`.

But I'm having a little trouble figuring out how to retrieve data on transaction fees.

Looking at the json when querying an address ([for example 1CK6KHY6MHgYvmRQ4PAafKYDrg1ejbH1cE](https://blockchain.info/address/1CK6KHY6MHgYvmRQ4PAafKYDrg1ejbH1cE?format=json)) I'm assuming I would need to iterate through the hash of transactions it returns, and use the hash of the transaction with the value "result" > 0?

I'm just not certain how to differentiate between spending and receiving when looking at the json.

**Tags:** transactions, api, transaction-fees

> **Comments:**
> **username_1**: that's a hard address to consider, why don't you look at one that has less transactions, like this one https://blockchain.info/address/1AdCDBz2VmhUZDyDbibMo2QGGSjt93zbRv  

---

## 1 answers

### Answer by username_2 on 2016-11-02. Score: 1 | Accepted answer

The API blockchain.info provides for the address details does a ton of processing at it's backend (by accessing the blockchain for which they must have maintained a separate db for quick fetches). As far as the transaction fee is concerned, it can be calculated by finding the difference in the inputs and outputs of a transaction. This is somewhat tricky because the vin (input) for any transaction points to the output of another transaction. But the point being you can find the difference and the transaction fee.

I suggest you query the blockchain using the core Bitcoin API and maintain your own database as per your convenience. The blockchain.info API is kind of a dependency for the app and if their server goes down, so does your app. So maintaining a custom formatted data on your side is a good way to go and also ensures responsiveness.


---

