Mining operations that manage more than a handful of ASICs typically need more than a web dashboard to track performance. A mining-pool API provides programmatic access to supported account, worker, and payment data, allowing that data to be pulled into external monitoring tools, spreadsheets, or internal reporting systems.

This article explains what a mining-pool API actually does, how it differs from the Stratum connection an ASIC uses to mine, what categories of data a pool API typically exposes, and what to check before relying on API data for reporting or reconciliation. The explanation draws on ViaBTC's published API documentation as a working example of how these interfaces are structured.

What API Integration Means for a Mining Pool

In a mining-pool context, API integration refers to connecting external software to the pool's account system through a defined set of HTTP endpoints, rather than through the pool's web interface. A mining operation might use this to build a custom dashboard that aggregates several accounts, to automate daily reporting for accounting purposes, or to trigger alerts when a worker's status changes.

It is important to be precise about scope. A pool API does not control mining hardware and does not participate in the process of finding and submitting valid shares. It is a reporting layer that sits on top of the pool's existing accounting system.

Stratum Connection vs. Pool HTTP API

These two interfaces are frequently conflated but serve entirely different functions.

The Stratum connection is the protocol an ASIC or mining proxy uses to receive work from the pool and submit completed shares back to it. Bitcoin's developer documentation describes this as a persistent two-way TCP connection between mining software and the pool, used to distribute block templates (or simplified jobs) and to receive share submissions in return (Bitcoin Developer Guide: Mining). This connection is configured directly on the ASIC or mining firmware, typically with a Stratum URL, a worker name, and an optional password.

A pool's HTTP API is a separate interface used to retrieve account information after the fact. It does not handle jobs or share submissions. ViaBTC, for example, documents its BTC Stratum endpoints (such as stratum+tcp://btc.viabtc.io:3333) and worker naming format separately from its API documentation, because the two serve different purposes: one connects the hardware, the other reports on what the hardware has already done (ViaBTC BTC Mining Setup Guide).

A practical way to keep this distinction clear: if a setting affects how the ASIC finds work, it belongs to the Stratum configuration. If a setting affects how external software reads pool data, it belongs to the API.

Data Available Through a Pool API

Most pool APIs organize data into a small number of categories. Using ViaBTC's documented endpoint groups as an example, these typically include:

• Account data — account information, subaccount lists, and observer access, used to understand how an operation's accounts and viewing permissions are organized.
• Hashrate data — account-level and worker-level hashrate fields, historical daily records, and worker status and group information.
• Wallet data — profit-summary fields, reward history, profit history, and payment history, used for financial reporting and reconciliation.

ViaBTC's account-hashrate endpoint, for instance, returns separate fields for the trailing 10 minutes, 1 hour, and 24 hours, expressed in hashes per second, along with counts of active and inactive workers (ViaBTC Account Hashrate API). The worker-level endpoint adds per-worker status, last-active timestamps, and a rejection-rate field. The documented API index lists these endpoint groups in full (ViaBTC Pool API Documentation).

Payment-history and profit-summary data belong to different stages of the accounting process and should not be treated as equivalent. A profit-summary response reflects the pool's internal accounting fields for a given coin or account context; a payment-history record is the pool's record of a payment, identified by an amount, destination address, transaction ID, and creation time. The documented payment-history response does not include a confirmation count or completion-status field. An operation reconciling its books should keep these data types separate and, where confirmed receipt is required, check the transaction on the relevant blockchain and the receiving wallet or platform. ViaBTC's deposit and withdrawal FAQ distinguishes transfer, blockchain confirmation, and crediting at the destination.

Keeping Pool-Side and Miner-Side Measurements Separate

The most common mistake when integrating pool API data is comparing it directly with local ASIC readings without accounting for differences in measurement source and time window.

A pool-reported hashrate field is a statistical estimate based on the work represented by accepted shares over a stated period, accounting for share difficulty. A local hashrate reading comes from the ASIC's own firmware, typically as a near-instantaneous or short-interval value. Share arrivals vary randomly, so even readings covering matching time windows can differ during normal operation (ViaBTC Pool Hashrate and Mining Statistics Explained). These two numbers can diverge for ordinary reasons, including network latency, share submission timing, and the different averaging windows each side uses. When comparing the two, align the time window explicitly — for example, compare a 24-hour pool-reported figure against a 24-hour average from local monitoring, not against an instantaneous dashboard reading.

The same discipline applies to the rejection-rate field. ViaBTC's historical hashrate endpoint documents reject_rate as a value between 0 and 1, applied to a daily record (ViaBTC Account Hashrate History API). The documentation does not break this figure down by rejection reason, so it should be treated as an account-level daily rejection rate rather than assumed to isolate stale shares specifically. Rejected shares are a broader category that can include stale, invalid, and duplicate submissions; a single rejection-rate field should not be read as measuring only one of these subcategories unless the source explicitly says so.

Timezone handling matters as well. ViaBTC's daily API records default to UTC+8. When comparing daily aggregates with UTC-based reports, request utc=true on endpoints that support it, including account hashrate history (ViaBTC API Description). Relabeling a UTC+8 daily record does not turn it into a UTC daily record, because the aggregation boundaries differ. Individual transaction timestamps can be converted for display or grouped into the required reporting timezone, but daily aggregates must already cover the same calendar-day boundaries before they are compared or merged.

Finally, a pool-reported hashrate field should not be used on its own to calculate a hardware efficiency figure such as J/TH. That calculation requires a measured power input from the hardware itself, over a matching time window — information a pool account API does not provide.

Authentication and Key Management

Because a pool API can expose account balances, worker lists, and payment records, access control is a meaningful part of evaluating any integration.

ViaBTC's API documentation describes a key-based authentication model: requests include an API key, and certain endpoints additionally require a signed request using HMAC-SHA256, with a millisecond timestamp parameter (tonce) and the key and signature passed in X-API-KEY and X-SIGNATURE headers (ViaBTC API Authentication Documentation). The documentation also states that an IP whitelist must be configured before the API can be called, with the setup guide specifying support for up to 20 listed addresses (ViaBTC API Setup Guide).

The account-hashrate, worker-information, profit-summary, and payment-history endpoints discussed here are documented as requiring no signature. Requests to these endpoints use the API key and remain subject to the IP-whitelist requirement; integrations should check each endpoint's authentication requirements rather than assume every request needs signing.

A dedicated API key separate from account login credentials and an IP restriction can reduce the exposure of pool-account data to unauthorized use. Request signing applies where an endpoint requires it. These controls do not eliminate risk on their own; API keys should still be stored securely, rotated when an integration changes, and restricted to only the IP addresses actually needed for a given monitoring or reporting system.

Evaluating a Mining Pool API

When reviewing whether a pool's API fits an operation's reporting needs, it is worth checking a few specific points rather than assuming all pool APIs are built the same way:

• Which time windows are available for hashrate data (e.g., 10-minute, 1-hour, 24-hour, or daily), and whether those windows match the operation's reporting cadence.
• Whether rejection-rate or similar fields are clearly scoped to an account, a worker, or a specific period.
• Whether historical data supports pagination and date filtering sufficient for the required reporting history.
• What timezone convention the API uses by default, and whether it can be overridden.
• What authentication mechanisms are required (API key only, or key plus signed requests) and whether IP whitelisting is supported.
• Whether payment-history and profit/reward data are returned as separate, clearly labeled response fields.

These are practical considerations for someone building a reporting pipeline, not a ranking of pools against one another — API design varies by provider, and a feature that matters for one workflow may be irrelevant for another.

ViaBTC's API Capabilities

ViaBTC's API covers account, hashrate, and wallet data. The full index of available endpoints is published in ViaBTC's Pool API documentation, with setup instructions, including API-key creation and IP-whitelist configuration, available in the API setup guide.

A simple monitoring integration can retrieve worker status and hashrate, store observations, and compare successive readings to generate its own alerts when a worker becomes inactive or its hashrate falls. A reporting integration can retrieve historical hashrate, profit, and payment records for periodic summaries, using matching date boundaries and checking confirmed receipt separately when needed. The external software supplies the storage, alert logic, and report generation; the API supplies the documented pool data.

These workflows operate independently of the Stratum settings used to connect mining hardware to the pool.

FAQ

Does a mining pool API replace the Stratum connection used to configure an ASIC?

No. The Stratum connection is what allows an ASIC to receive work and submit shares to the pool; it is configured directly on the mining hardware or firmware. The API is a separate HTTP interface used to retrieve account, worker, and payment data after mining activity has already occurred. Configuring API access does not affect how, or whether, an ASIC connects to the pool.

Can API hashrate data be used to calculate my hardware's efficiency in J/TH?

Not reliably on its own. A pool-reported hashrate field reflects the pool's estimate based on accepted-share work over a stated window, not a measured power reading from the hardware. Calculating a hardware efficiency figure requires a measured power input from the ASIC itself over a matching time period, which a pool account API does not provide.

What does the rejection-rate field in a pool API represent?

It depends on the specific endpoint's documentation. For example, ViaBTC's account hashrate history API defines reject_rate as a value between 0 and 1 for a given daily record, without breaking it down into stale, invalid, or duplicate share categories. Treat it as an account-level or worker-level rejection rate for the stated period, not as a measure of one specific rejection cause unless the source defines it that way.

Is a profit-summary field the same as a completed payout?

No. A profit-summary response (such as pplns_profit, pps_profit, solo_profit, or total_profit in ViaBTC's documentation) reflects the pool's internal accounting fields. A payment-history record is the pool's record of a payment and includes a transaction ID and destination address, but the documented response does not establish blockchain confirmation or credit at the destination. Keep these data types separate during reconciliation and verify confirmed receipt with the relevant blockchain and receiving wallet or platform when required.

What should I check before granting API access to a third-party monitoring tool?

At minimum, review what authentication method the integration uses, whether the pool supports IP whitelisting for the API key, and what data scope the key grants. Limiting a key to read-only endpoints where that option exists, and restricting it to known IP addresses, reduces the exposure of account data if the integration's credentials are compromised.

References

• Bitcoin Developer Guide: Mining
• ViaBTC API Setup Guide
• ViaBTC Pool API Documentation
• ViaBTC API Authentication Documentation
• ViaBTC BTC Mining Setup Guide
• ViaBTC Account Hashrate API
• ViaBTC Account Hashrate History API
• ViaBTC Worker Hashrate Information API
• ViaBTC Profit Summary API
• ViaBTC Payment History API
• ViaBTC API Description
• ViaBTC FAQ About Deposit and Withdrawal
• ViaBTC Pool Hashrate and Mining Statistics Explained