We just switched from GraphQL to REST APIs. Here’s why: We built our API for developers. Our customers weren’t developers.

When we first built our Mining Pool and HashrateIndex UIs, we chose GraphQL because it made our lives easier as developers. The elegant data fetching, type safety, and ability to query exactly what we needed were huge benefits for us.

But we made a classic mistake: we optimized for ourselves, not our users. What we thought was a forward-thinking, scalable decision instead became a barrier between our product and the people trying to integrate with it.

Not every Bitcoin miner has software engineers on staff. Many are solo operators, home-miners, or smaller operations who need simple, straightforward access to their data.

GraphQL is powerful, but it comes with a learning curve. You need to understand: query structure, schema navigation, and new patterns.

For a miner who just wants to check their hashrate or earnings, that’s unnecessary complexity.

REST, on the other hand, is everywhere. It’s the standard language of web APIs.

• Need hashrate? GET /v1/pool/hashrate-efficiency/BTC
• Need revenue? GET /v1/pool/revenue/BTC

No query languages. No schema exploration. Just simple HTTP requests that work in any tool — even Excel.

Miners want to check their hashrate, pull revenue data, and get back to running their operations — what they do best. They don’t want to spend hours fumbling through documentation trying to understand a new query language.

When your customer base ranges from enterprise operations to individual miners running a few ASICs in their garage, accessibility matters more than elegance.

The “best” technology isn’t always the right technology. Sometimes, the boring, familiar choice is exactly what users need.