Your mining data,
connected.

Example API request

The monitoring API lets your software read your mining activity automatically: account hashrate, worker status, share statistics, fees, estimated earnings, and confirmed payout-output history. Access is read-only.

This Python example reads the latest account hashrate. It uses the following credentials and permission:

• Monitoring token. A dedicated token created in the dashboard’s API Keys page for the exact account being monitored.
• Required permission. The token needs the hashrate_read scope.
• Secret storage. The token is stored in the monitoring system’s secret store and supplied through the secret manager as DEMAND_MONITORING_TOKEN.

import json
import os
import urllib.request

request = urllib.request.Request(
    "https://api.dmnd.work/api/v1/user/hashrate",
    headers={
        "Authorization": "Bearer " + os.environ["DEMAND_MONITORING_TOKEN"],
        "Accept": "application/json",
    },
)
with urllib.request.urlopen(request, timeout=20) as response:
    snapshot = json.load(response)
print(snapshot)

This example makes one request, sets a timeout, and prints the decoded response without logging the token. It does not retry. Before scheduling it to run repeatedly, add error handling and follow the polling guidance.

API keys & permissions

A monitoring token is a secret that tells DMND which account and data your tool may access. Send it in the Authorization header on every request.

Authorization: Bearer <token>

Create a dedicated monitoring key in the dashboard’s API Keys page, selecting the exact account and only the required scopes. Mining tokens and FPPS credentials won’t work here. Programmatic clients should send no session cookies; if both a session and a bearer token are supplied, the bearer token decides the account and permissions.

Choose what you want to read

Each path below is relative to the base URL. All endpoints use GET to read the data described in this reference.

These routes read the token’s account. Earnings and payouts also include directly owned subaccounts. To select one exact account, use the subaccount routes.

Detailed PPLNS projections and the combined dashboard summary are dashboard interfaces outside the versioned monitoring contract. Mining telemetry, payment initiation, registration, and session management are also outside this API.

Hashrate

Requires hashrate_read

Read the latest account snapshot, with separate PPLNS, FPPS, and total rates. This endpoint returns all three in raw hashes per second (H/s).

{
  "account_id": "9223372036854775807",
  "observed_at": "2026-09-08T10:00:00Z",
  "pplns_hashrate": 150000000000000,
  "fpps_hashrate": 50000000000000,
  "total_hashrate": 200000000000000
}

Snapshots are normally saved every two minutes using fresh worker telemetry. A worker counts as online while its latest telemetry is less than ten minutes old. These are periodic snapshots, so they may differ from an instantaneous miner reading.

Looking back in time

This returns an array of snapshots in ascending observed_at order—oldest first. Supply from and to as RFC3339 timestamps or YYYY-MM-DD dates. Omitted bounds default to the last 24 hours.

Each request covers at most seven days and returns at most 6,000 points. Approximately 100 days are retained. To collect a longer history, request successive windows up to seven days each and remove duplicate boundary timestamps. Fix the range before your first request so its end does not move between pages. An empty array means there are no snapshots in that window.

Workers

Requires workers_read

Use /workers for live workers, or /workers/all to include offline workers. Results come in pages of 200 workers by default; use limit to request up to 1,000.

Responses have the shape {"workers": [...], "next_cursor": "..."}. Pass next_cursor back unchanged as cursor for the next page; it is opaque, so your client should not interpret it. When it is null, you’re done.

Missing telemetry for a payout mode is null. Worker counters can reset, disconnected miners can affect changes between readings, and the worker list can change while you fetch pages.

Shares & fees

Check your rejection rate

Requires rejects_read

This endpoint reports changes in accepted and rejected share counters over your chosen window. The hours parameter defaults to 24 and can be at most 168 (seven days).

The response includes window_hours, pplns_accepted, pplns_rejected, fpps_accepted, fpps_rejected, accepted, and rejected.

These numbers come from telemetry counter changes, rather than an immutable record of every raw share.

Read your pool and broker fees

Requires fees_read

The response contains pool_fee and broker_fee. Both are fractions: 0.02 means 2%.

Estimated earnings, day by day

Requires earnings_read · Includes directly owned subaccounts

Read daily generated FPPS BTC alongside projected PPLNS BTC. Results are an array ordered by entry_day, newest first. Every day is measured in UTC.

Collecting older earnings

Use the preceding calendar window to collect older data. Missing mining days are omitted, so a page with missing days does not mean older data is unavailable.

For both account and subaccount routes, a request for one specific date with no earnings returns one zero-earnings row. Its PPLNS hashrate still follows the independent recorded-work availability rules. The FPPS earnings accumulator normally runs every five minutes.

Compatibility note: unversioned dashboard earnings routes under /api return complete available history when these parameters are omitted, so dashboard history and exports do not need pagination. New integrations using /api/v1 use the bounded defaults above.

Confirmed payouts

Requires earnings_read · Includes directly owned subaccounts

Read confirmed FPPS and PPLNS transaction outputs sent to your account’s recorded Bitcoin addresses, including inactive addresses. Unrelated recipients, transfers back to funding addresses, unrelated deposits, and unconfirmed transactions are excluded. This API only reads history; it never initiates payments or changes payout addresses.

https://api.dmnd.work/api/v1/user/payouts?from=2026-09-01&to=2026-09-09&limit=100

{
  "payouts": [
    {
      "txid": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
      "output_index": 2,
      "kind": "fpps",
      "address": "<recorded Bitcoin address>",
      "amount_sats": 125000,
      "confirmed_at": 1788912000
    }
  ],
  "next_cursor": null,
  "as_of": 1788912300,
  "from": "2026-09-01",
  "to": "2026-09-09"
}

• amount_sats is an integer number of satoshis, never a floating-point BTC amount.
• txid and the zero-based output_index together identify a unique transaction output. Each pair appears once.
• kind is fpps or pplns.
• confirmed_at is the block timestamp in Unix seconds, not the payment request time. as_of is when the server retrieved the snapshot, also in seconds.
• next_cursor: null means the last page. Rows are ordered descending by confirmation timestamp, then transaction ID and output index.

An empty page means there are no matching confirmed outputs in a fully retrieved window, or no recorded recipient addresses. A failed or incomplete provider read returns an error, never a successful empty or partial history.

When a payout snapshot changes

Bitcoin confirmations can change after a chain reorganization. If you receive 409 payouts-cursor-changed, restart without a cursor using the same fixed date window. Compare the replacement results with what you collected, using txid and output_index, so removed or changed outputs are reconciled.

A change to the funding snapshot, requested dates, target account, or recorded recipient addresses invalidates the cursor with 409 payouts-cursor-changed. A funding change can affect another recipient, even if your own payouts look unchanged.

Monitoring subaccounts

A token can read its own account and directly owned subaccounts, within its selected permissions. A key created for a subaccount cannot read the master account or sibling subaccounts.

To read one exact account, replace {id} in the paths below with that account’s ID. Unlike the main earnings and payout routes, these routes do not include that target’s subaccounts.

One important difference: hashrate units

Subaccount hashrate snapshots return each rate as a value/unit object, rounded to two decimal places, using TH/s or PH/s. This applies to current and historical hashrate routes. Worker rates still use raw H/s.

{
  "account_id": "1234567890123456789",
  "observed_at": "2026-09-08T10:00:00Z",
  "pplns_hashrate": {"value": 150.0, "unit": "TH/s"},
  "fpps_hashrate": {"value": 50.0, "unit": "TH/s"},
  "total_hashrate": {"value": 200.0, "unit": "TH/s"}
}

Outputs to an address shared entirely within an aggregate account group can appear in that group’s history. Each (txid, output_index) appears once. The corresponding exact-account request is ambiguous and returns 409 payouts-ambiguous-address when another recorded owner is outside that exact target.

How often should I check?

Every two to five minutes is an appropriate interval for current statistics, matching the snapshot cadence. Check payouts every few minutes, too.

• Save collected data in your own monitoring store. Fetch only what you need instead of the entire history each time.
• Stagger requests across accounts and limit how many run at once.
• Set connection and request timeouts. Give payout requests enough time for their provider lookup.

These limits apply per server process, not as a guaranteed cluster-wide allowance. Payout lookups have additional request budgets. Edge protection or temporary capacity limits may also reject traffic. Always obey a 429, even if your own request count is lower. The separate limits for supplemental PPLNS-rate refreshes return null when a refresh is unavailable, as described under estimated earnings.

Account responses use Cache-Control: private, no-store. Do not record bearer headers, API secrets, watcher links, or responses that create or list credentials in request logs, traces, or alerts.

When a request doesn’t work

Errors are JSON objects with code and message strings. Use the HTTP status to decide whether to retry. The message is for diagnosis and may change.

Two payout errors to handle differently

payouts-ambiguous-address: an address is recorded against an account outside your requested group. The entire request returns 409 instead of guessing attribution or silently omitting that address.

payouts-cursor-changed: the pagination snapshot or request context changed. Restart the same fixed window without a cursor and reconcile your saved outputs with the replacement results.

For transient server errors, retry with bounded exponential backoff. Don’t keep retrying 400, 401, or 403.

Reading the values

Account and subaccount hashrate

The account hashrate endpoint returns raw H/s. Subaccount hashrate routes return value/unit objects in TH/s or PH/s, rounded to two decimal places. Worker hashrates remain raw H/s on both account and subaccount routes.

Estimated earnings and payout history

Generated-BTC results combine generated FPPS BTC with cached future PPLNS projections. That combined amount is not a paid balance, payout guarantee, or settled accounting record. Payout history reports confirmed outputs associated with recorded addresses.

Dates and timestamps

Earnings days and payout date windows use UTC. Worker connected_at values use Unix milliseconds or null; payout confirmed_at and as_of values use Unix seconds.

Missing PPLNS hashrate

For earnings rows, pplns_hashrate: null means the rate is unavailable. A covered day that was read successfully and had no recorded work returns pplns_hashrate: 0. Unavailable rates are never reported as zero. Do not replace null with zero.

Pages of results

Worker and payout responses use next_cursor to continue to the next page; null marks the last page. Earnings use calendar-day windows instead.