Know exactly what your transaction will cost before you hit send. Satoshi API estimates fees based on your transaction shape and current mempool conditions.
Three endpoints that turn fee rates into actual transaction costs — so your users see a dollar amount, not a sat/vB number they have to decode.
The core calculator endpoint. Pass the number of inputs and outputs in your transaction and get back the estimated virtual size plus the total fee in satoshis at three priority tiers. This is what wallets need to show a fee preview before the user signs.
Human-readable fee recommendations with three priority tiers: high (next block), medium (within 6 blocks), and low (within 24 blocks). Returns the sat/vB rate for each tier plus a plain-language recommendation. Multiply the rate by your transaction's vBytes to get the total cost.
The "should I send now or wait?" decision engine. Analyzes fee spread, urgency premium, and mempool congestion to give you a send/wait verdict. If your transaction is not urgent, this endpoint tells you whether waiting could save money.
Bitcoin transaction fees are not based on the amount of BTC you send. They are based on how much block space your transaction consumes, measured in virtual bytes (vBytes).
Every Bitcoin block has a maximum weight of 4 million weight units, which translates to roughly 1 million vBytes of transaction data. When more transactions compete for that space, the fee rate (measured in sat/vB) goes up. When demand drops, fees fall.
Your transaction's size in vBytes depends on three things:
The total fee formula is straightforward: fee = vBytes x sat/vB rate. A 226 vByte transaction at 10 sat/vB costs 2,260 satoshis. At $85,000/BTC, that is about $1.92. The same transaction at 50 sat/vB costs 11,300 satoshis (~$9.60).
Miners prioritize transactions with higher sat/vB rates. If you set your fee too low, your transaction sits in the mempool until congestion clears. If you set it too high, you overpay for block space you did not need to bid on.
Most Bitcoin users overpay on transaction fees because their wallet picks a fee rate without context. A fee calculator API fixes this by giving your application three capabilities:
The /fees/estimate-tx endpoint takes input and output counts and returns the total fee in satoshis at three priority levels. Your users see "this transaction will cost 2,192 sats (~$1.86)" instead of a cryptic "9.7 sat/vB" number they cannot interpret.
The /fees/landscape endpoint analyzes current mempool conditions and returns a send-or-wait recommendation. If fees are temporarily elevated, it tells your app to wait. On a typical week, the difference between peak and off-peak fees can be 5-10x — that is real money on larger transactions or high-volume payment flows.
Satoshi API refreshes fee data from your Bitcoin Core node every 10 seconds. Many wallets use hardcoded fee rates or poll infrequently, leading to overpayment during fee drops or stuck transactions during fee spikes. Real-time data means your fee estimate matches what miners actually expect right now.
A raw fee rate (like "8 sat/vB") tells you the price per unit of block space, but it does not tell you what your transaction will actually cost. That is like knowing the price per gallon of gas without knowing how many gallons your car needs.
To turn a fee rate into a total cost, you need to know your transaction's size in vBytes. That depends on how many UTXOs you are spending (inputs) and how many addresses you are paying (outputs). A consolidation transaction with 10 inputs is much larger than a simple payment with 1 input.
This is why the /fees/estimate-tx endpoint exists. It combines the size estimation and the fee rate lookup into a single call:
# Raw fee rate — useful but incomplete curl https://bitcoinsapi.com/api/v1/fees/recommended # Returns: 9.7 sat/vB for medium priority # Fee calculator — the full picture curl "https://bitcoinsapi.com/api/v1/fees/estimate-tx?inputs=3&outputs=2" # Returns: 294 vBytes, total fee 2,852 sats at medium priority
For wallets and payment processors, the calculator endpoint is the one to integrate. For dashboards and monitoring tools that just need the current fee environment, the raw rate endpoints are sufficient.
How different approaches to calculating Bitcoin transaction fees stack up.
| Satoshi API | Mempool.space (manual) | Wallet Default Fee | |
|---|---|---|---|
| Total fee calculation | Automatic — pass inputs/outputs, get total sats | Manual — check fee rate, estimate size yourself | Automatic but opaque — no breakdown shown |
| Priority tiers | 3 tiers (high / medium / low) with total cost each | 4-5 tiers but sat/vB only, no total | Usually 1-2 options (fast / normal) |
| Send or wait advice | Yes — /fees/landscape with congestion analysis | No — fee rate display only | No |
| Programmatic access | REST API, JSON responses, no auth for GET | API available but no tx cost endpoint | Locked inside the wallet UI |
| Self-hostable | Yes — pip install, point at your node | Yes but heavy infrastructure | No |
| Privacy | Full — your node, your queries | Public instance sees your queries | Depends on wallet |
| Real-time updates | Every 10 seconds + SSE stream | WebSocket | Refreshes on wallet open |
| Cost | Free tier + free self-hosting | Free | Free (bundled with wallet) |
Multiply your transaction's virtual size (in vBytes) by the current fee rate (in sat/vB). A typical single-input, two-output SegWit transaction is about 141 vBytes. At a fee rate of 10 sat/vB, the total fee would be 1,410 satoshis. Satoshi API's /fees/estimate-tx endpoint does this math for you — pass the number of inputs and outputs and it returns the total fee at three priority tiers.
Transaction size in virtual bytes (vBytes) depends on the number of inputs, the number of outputs, and the script type used. Each native SegWit input adds roughly 68 vBytes and each output adds about 31 vBytes, plus a fixed overhead of ~11 vBytes. Legacy (P2PKH) inputs are larger at ~148 bytes each. Using fewer inputs and native SegWit addresses keeps transactions smaller and cheaper.
Four practical strategies: (1) Time your transaction using /fees/landscape to find low-congestion windows, often weekends or early UTC mornings. (2) Use native SegWit (bech32) addresses, which produce smaller inputs than legacy addresses. (3) Consolidate UTXOs during low-fee periods so future transactions need fewer inputs. (4) Batch multiple payments into a single transaction when possible.
Yes. Satoshi API offers a free hosted tier that includes the /fees/estimate-tx endpoint — pass your input and output count and get back the estimated vBytes and total fee in satoshis at three priority levels. No API key is required for GET requests. You can also self-host the entire API on your own Bitcoin Core node for unlimited, private fee calculations at zero cost.
Try the fee calculator endpoint right now — no signup required:
# Simple payment (1 input, 2 outputs) curl "https://bitcoinsapi.com/api/v1/fees/estimate-tx?inputs=1&outputs=2" # Consolidation (5 inputs, 1 output) curl "https://bitcoinsapi.com/api/v1/fees/estimate-tx?inputs=5&outputs=1" # Should I send now or wait? curl https://bitcoinsapi.com/api/v1/fees/landscape