API keys & permissions.

01 What API keys are for

API keys let you talk to the dashboard programmatically — pull pool statistics into a status page, wire a monitoring script, or automate a routine task — without sharing your login password or sitting a script behind two-factor authentication. Each key is a credential you can scope tightly, restrict by network, and revoke on its own without touching the rest of your account.

Because a key acts on behalf of your account, the dashboard treats issuing one as a sensitive action: creating a key requires a fresh 2FA code. Manage keys under Settings → API keys.

02 Create a scoped key

From Settings → API keys, choose Create key, give it a clear name (for example status-page or prometheus-scraper), and pick a scope:

• Read-only stats — the key can fetch figures such as pool hashrate, connected workers and settlement history. It cannot change anything. This is the right scope for dashboards, monitoring and reporting.
• Read-write — the key can additionally perform actions through the API. Only issue this when an integration genuinely needs to make changes, and prefer a separate key per integration so you can revoke one without disrupting the others.

Confirm with your 2FA code to finish. The key’s secret is shown to you once at this point — see keep the secret safe below.

03 Least privilege & IP allow-listing

Two settings narrow what a key can do if it ever leaks:

• Least privilege. Give each key the smallest scope that still lets its job run. A status page needs read-only stats and nothing more; handing it read-write access only widens what an attacker gains from a stolen key. One key per integration, scoped to that integration’s needs, keeps the blast radius small.
• IP allow-listing. Optionally bind a key to one or more source IP addresses (or ranges). The dashboard then rejects any request bearing that key from anywhere else, so a copied key is useless away from your server’s address.

04 Authenticate a request

Send the key in an Authorization header as a Bearer token. Keep it in an environment variable rather than pasting it inline, so it never lands in your shell history or a committed file:

A read-only key against a write endpoint comes back 403 Forbidden; a key sent from an address outside its allow-list is rejected before the request is processed. Always call the API over HTTPS so the key is never sent in clear text.

05 Keep the secret safe

The full key secret is displayed only once, at the moment you create it. The dashboard stores a hash, not the secret itself, so it genuinely cannot show it to you again later — that is the point.

• Copy it straight into your secret store, your deployment’s environment, or a password manager.
• Never commit it to a repository, paste it into a ticket or chat, or log it. If a key reaches any of those, treat it as compromised.
• If you lose the secret, you do not recover it — you revoke the key and create a new one.

06 Rotate and revoke

Keys are independent, so you can manage them without disturbing your login or your other integrations:

• Rotate a key periodically — create its replacement, deploy the new secret, then revoke the old key once nothing depends on it. Issuing the replacement requires a 2FA code, like any key creation.
• Revoke a key the moment you suspect it has leaked, when an integration is retired, or when someone with access leaves. Revocation takes effect immediately and cannot be undone; any request still using that key starts failing at once.