Sources and endpoints
Data & API
Every upstream data source BitcoinTrench uses, what it supplies, its refresh policy, and the internal endpoints built on top of it.
Architecture
How data reaches this page.
Your browser talks to BitcoinTrench, and BitcoinTrench talks to the providers. That single indirection is what lets the platform cache, fall back, normalise units and keep provider credentials off the client — and it is why one provider outage does not blank the site.
Browser → /api/bitcoin/* → service layer (normalise, validate, fall back) → provider adapters → public Bitcoin data sources
Two things bypass this deliberately: the live price WebSocket, because a cached stream is not a stream, and exchange order books, because a book cached even for twenty seconds can show a crossed market. Everything else is served through the internal API with edge caching and stale-while-revalidate.
Upstream
Every source BitcoinTrench uses.
| Source | Category | Supplies | Key | Attribution | Notes |
|---|---|---|---|---|---|
| Loading source registry… | |||||
BitcoinTrench runs entirely on free, public tiers. No source on this list requires a paid plan, and the platform functions without any API key at all.
Endpoints
The internal API.
Loading endpoint catalogue…
These endpoints exist to serve BitcoinTrench itself and are documented for transparency, not published as a product. They may change without notice, and heavy automated use is rate limited.
Response shape
One contract, every endpoint.
Success
{
"success": true,
"data": { … },
"source": "mempool.space",
"timestamp": 1780000000000,
"cached": true,
"stale": false
}
Failure
{
"success": false,
"error": {
"code": "PROVIDER_UNAVAILABLE",
"message": "Unable to retrieve this
Bitcoin data set from any
configured source."
},
"timestamp": 1780000000000
}
Error codes are stable machine tokens. Provider error text, stack traces, hostnames and environment values are never included.
Cache policy
How long each category is held.
| Category | Edge cache | Character |
|---|---|---|
| Loading cache policy… | ||
Each lifetime is chosen from how fast the underlying metric can actually change and how heavily it is fair to lean on a free public provider. Every response also carries a stale-while-revalidate window, so a slow provider produces a slightly older number rather than a blank one.