WholesaleBackup Web Console: API for RMM

The WholesaleBackup RMM API lets your RMM or monitoring tool read the backup status of every device you manage: whether the last backup succeeded, how much is stored, what went wrong, and which devices need attention. With a key that allows it, your tool can also act on a device: start or stop a backup, restart the backup service, sync settings, reform databases, and change the device's status or custom field. It can't change backup settings or restore data; do those in the Web Console.

This article is the general reference. It works with any tool that can make an HTTPS request and read JSON, such as NinjaOne, N-able, Datto RMM, Syncro, ConnectWise, a PowerShell script or a monitoring system.

Contents

• Overview
• Getting an API key
• Making requests
• Identifying a device
• Endpoints
• Status values
• Remote commands
• Changing a device
• Field reference
• Errors and rate limits
• Tips for RMM scripts

Overview

• Base URL: https://dash.backupops.com/v1/
• Authentication: an API key, sent as Authorization: Bearer <key> on every request.
• Format: every response is JSON. Requests that send data (commands and changes) send JSON too.
• Access: a key sees the same devices its owner sees in the Web Console. Keys are read-only unless you allow remote commands and changes when you generate them.
• Encryption: HTTPS only, TLS 1.2 or newer.

Getting an API key

1. Sign in to the Web Console.
2. Open the user menu (your username, top right) and choose API Keys.
3. Optionally enter a label (for example NinjaOne) so you can tell your keys apart.
4. If this key should be able to send remote commands and change devices, tick Allow remote commands and changes. Leave it unticked for keys that only monitor.
5. Click Generate new key.
6. Copy the key straight away. For your security it is shown only once. If you lose it, revoke it and generate a new one.

Keys look like rmm_live_ followed by a long random string. Treat a key like a password: anyone who has it can read your backup status, and a key that allows commands can also start and stop backups. Store it in your RMM's secure or secret variables, not in plain script text.

You can create as many keys as you like. A separate key for each tool makes it easy to replace one without affecting the others. To stop a key working, click Revoke next to it on the API Keys page. It stops working immediately.

Read only or read + write

The Access column on the API Keys page shows what each key can do:

• Read only: the key can read devices, backup history and alerts. This is the default, and all a monitoring integration needs.
• Read + write: the key can also send remote commands and change a device.

A key's access can't be changed after it is generated. To change it, generate a new key with the access you want and revoke the old one.

What a key can see

• Partner accounts: every device under your brands and accounts.
• Subusers: only the brands and accounts assigned to them. If those assignments change, the key's access changes with them; there's no need to create a new key.
• Subusers sending commands or changing status also need the matching permission in their Web Console settings: Remote Management to send commands, and Edit Computer Status to change a device's status.
• Devices that have been deleted, or that sit under a suspended or deleted account or brand, are not returned. Suspended devices are returned, with computer_status Suspended.
• If your license is suspended, requests return 403 until it is reactivated.

Making requests

Send the key in the Authorization header. For example, with curl:

curl -H "Authorization: Bearer rmm_live_YOUR_KEY" "https://dash.backupops.com/v1/endpoints?limit=50"

Or with PowerShell:

$headers = @{ Authorization = "Bearer rmm_live_YOUR_KEY" }
Invoke-RestMethod -Uri "https://dash.backupops.com/v1/endpoints?limit=50" -Headers $headers

Requests that send data (POST and PATCH) send a JSON body with the header Content-Type: application/json:

curl -X POST -H "Authorization: Bearer rmm_live_YOUR_KEY" -H "Content-Type: application/json" \
  -d '{"command": "start_backup"}' "https://dash.backupops.com/v1/endpoints/12345/commands"

$headers = @{ Authorization = "Bearer rmm_live_YOUR_KEY" }
$body = @{ command = "start_backup" } | ConvertTo-Json
Invoke-RestMethod -Method Post -Uri "https://dash.backupops.com/v1/endpoints/12345/commands" -Headers $headers -ContentType "application/json" -Body $body

Paging

Lists are returned a page at a time, in this envelope:

{
  "count": 137,
  "next": "https://dash.backupops.com/v1/endpoints?limit=50&offset=50",
  "previous": null,
  "results": [ ... ]
}

• limit: how many results per page. Default 50, maximum 200.
• offset: how many results to skip.
• count: the total number of results across all pages.
• next / previous: the full URL of the next or previous page, or null. To read everything, keep requesting next until it is null.

Identifying a device

Every device has a computer_id: a stable number that identifies exactly one device and never changes. It’s the best way to match a device in your RMM to its backup status.

1. Find the device’s regcode. A regcode is four numbers separated by colons, e.g. 1001:2002:3003:12345. You can get it either way:
   • In the Web Console: on the Storage, Transfers or Remote Manager page, use the table’s column picker to show the hidden Regcode column.

   • On a Windows device, from the backup client. Run it as an administrator. It can take up to about 30 seconds.

     • YourBrandName.exe -getregcode, from the backup client’s install folder (Located in C:\Program Files\YourBrandName\ by default)

     If the command doesn’t respond, the backup client is an older version that doesn’t support it yet. Use the Web Console instead.

2. Take the computer_id from it. It’s the last of the four numbers: 1001:2002:3003:12345 → 12345. You can also look the device up directly with /v1/endpoints?regcode=1001:2002:3003:12345.
3. Store the computer_id in your RMM, in a custom field on each device, and match the API’s results on it.

If you can’t get a regcode, you can search by hostname instead. Hostnames are not unique, so add the brand and account filters and check that exactly one device is returned.

Endpoints

Fetching one device

There are three ways to get a single device. They differ in what you supply and in the shape of the response:

With the filters, read the device from results and check that count is 1.

GET /v1/endpoints

Every device the key can see, each with its current status and the details of its latest backup. Results are ordered by computer_id.

Optional filters, which can be combined:

GET /v1/endpoints?regcode=1001:2002:3003:12345
GET /v1/endpoints?hostname=example-pc@workgroup&brand=AcmeBackup&account=Main_Office

GET /v1/endpoints/{computer_id}

One device, by its computer_id. The response is a single device object (no paging envelope). Returns 404 if the device doesn't exist or the key can't see it.

computer_id is the stable identifier for a device. Find it with the list endpoint, or take it from the device's regcode: it is the last of the four numbers. This endpoint accepts only the computer_id, not a full regcode.

Have a regcode or hostname instead of a computer_id? Use the filters on /v1/endpoints. They return the usual list, normally with one device in results. Check that count is 1.

GET /v1/endpoints/{computer_id}/backups

The device's backup history, newest first, one record per backup run. Restores, test connections and other job types are not included. Paged like the list endpoint.

GET /v1/alerts

Only the devices that need attention: those whose status is warning, failed or stale. Suspended devices are included: they don't back up, so they show as stale; check computer_status to tell them apart. Same device objects and paging as /v1/endpoints. This is the simplest way to drive alerts in your RMM. Its rate limit is lower than the other endpoints' (see Errors and rate limits).

Status values

Every device has one status, based on its latest backup run. It matches the row colours in the Web Console's Transfers page.

New status values may be added in future versions. Treat any value you don't recognise as needing attention.

status follows the same rules as the Web Console, so in rare cases a device can be ok while error_count is above zero. Alert on status, and use the counts and messages for detail.

status is the device's backup health and can't be changed. Don't confuse it with computer_status, the device's Active, Trial, Test or Suspended status in the Web Console, which you can change.

Remote commands

With a Read + write key you can send a device the same commands as the Web Console's Remote Manager. The device must be checking in with Remote Manager, which means it appears on the Web Console's Remote Manager page.

How commands are delivered

Commands work exactly as they do in Remote Manager: the command waits on our server, and the device picks it up the next time it checks in, normally within about 30 seconds. So sending a command and the device acting on it are two separate steps:

1. Send it with POST. A 202 response means the command is queued.
2. Check it was picked up with GET. pending_command goes back to null once the device has taken it.
3. See the result on the device itself, e.g. its status becomes running after start_backup.

Only one command waits for a device at a time. If you send a command while an earlier one from the API is still waiting, the new one replaces it and the response names the one it replaced.

POST /v1/endpoints/{computer_id}/commands

Send {"command": "<name>"} with one of the names above.

POST /v1/endpoints/12345/commands
{"command": "start_backup"}

202 Accepted
{
  "computer_id": "12345",
  "command": "start_backup",
  "state": "queued",
  "replaced_command": null,
  "agent_last_seen": "2026-10-12T08:41:30Z",
  "agent_last_seen_display": "20 seconds ago",
  "check_in_interval_seconds": 30
}

• replaced_command: the command this one replaced, or null.
• agent_last_seen: when the device last checked in with Remote Manager. Has a _display twin.
• check_in_interval_seconds: how often the device checks in, so roughly how long until it picks the command up.

To withdraw a waiting command, send {"command": "cancel"}. It takes effect immediately and returns 200:

{
  "computer_id": "12345",
  "command": "cancel",
  "state": "cancelled",
  "cancelled_command": "start_backup",
  "agent_last_seen": "2026-10-12T08:41:30Z",
  "agent_last_seen_display": "25 seconds ago",
  "check_in_interval_seconds": 30
}

state is cancelled, or nothing_pending if no command was waiting. A command the device has already picked up can't be withdrawn: to end a backup that has started, send stop_backup.

A command is refused with 409 when:

• the device isn't checking in with Remote Manager, so it can't take commands;
• someone is using Remote Manager for the device in the Web Console, e.g. a restore window is open; try again in a few minutes;
• a command sent from the Web Console (e.g. a restore) is waiting for the device. The API won't replace or cancel it;
• you send start_backup to a suspended device. Set its computer_status back to Active, Trial or Test first.

GET /v1/endpoints/{computer_id}/commands

Whether a command is waiting for the device. Works with any key.

{
  "computer_id": "12345",
  "remote_management": true,
  "pending_command": null,
  "agent_last_seen": "2026-10-12T08:41:30Z",
  "agent_last_seen_display": "20 seconds ago",
  "check_in_interval_seconds": 30
}

• remote_management: whether the device checks in with Remote Manager. If false, it can't take commands and the other fields are null.
• pending_command: the name of the command waiting for the device, other for a command sent from the Web Console, or null if nothing is waiting.

Changing a device

With a Read + write key you can change two things about a device, the same as you can in the Web Console:

• computer_status: the device's status, Active, Trial, Test or Suspended.
• custom_field: the device's Custom Field, free text of up to 200 characters.

PATCH /v1/endpoints/{computer_id}

Send either field or both. The response is the updated device object, the same as GET /v1/endpoints/{computer_id}.

PATCH /v1/endpoints/12345
{"computer_status": "Active", "custom_field": "Head office server"}

• computer_status can be set to Active, Trial, Test or Suspended. A suspended device stops backing up until you set it back to Active, Trial or Test, which you can also do through the API. Delete devices in the Web Console. Changing the status has the same effect as changing it in the Web Console.
• computer_status can't be changed through the API for brands that run on their own WSBU Server; change it on that server.
• custom_field: leading and trailing spaces are removed. Send null or "" to clear it. The device must have backed up at least once.
• The request is checked in full before anything is saved, so if any part is refused (400 or 403), nothing changes.
• Only these two fields can be changed. Sending any other field, including status, returns 400.

Field reference

How values are formatted

• Large numbers are strings. Byte and file counts, and computer_id and session_id, are returned as strings (for example "1048576") so they stay exact in languages that can't hold very large integers. Convert them to numbers before doing arithmetic.
• Readable twins. Byte, duration and timestamp fields have a matching *_display field that is ready to show, e.g. stored_bytes = "1048576" and stored_display = "1.0 MB". Timestamps' twins are relative, e.g. "2 hours ago". Do calculations on the raw value; show the twin as it is.
• Timestamps are ISO 8601 in UTC, e.g. 2026-01-15T09:30:00Z.
• Missing values are null.
• Unknown sizes are null, not zero. If a backup client reports an impossible size (1 PB or more for one device), that byte field and its _display twin are null. When adding up storage, skip null values rather than counting them as zero.
• Devices that have never backed up have status stale and no backup-run fields.
• Stable names. Field names won't change within /v1/. New fields may be added, so ignore any you don't use.

Device identity

Storage

What the device has stored, from its latest backup. stored_bytes is the space actually used after deduplication; selected_bytes and restorable_bytes are the logical size of the data, so they can be larger than stored_bytes.

Backup run

Details of one backup run. On /v1/endpoints and /v1/alerts these describe the device's latest backup; on /backups each record is one past run.

Records from /backups contain hostname, custom_field and status (the status of that run), plus the backup-run and storage fields.

Example

GET /v1/endpoints/12345

{
  "hostname": "example-pc@workgroup",
  "custom_field": null,
  "computer_id": "12345",
  "regcode": "1001:2002:3003:12345",
  "status": "warning",
  "computer_status": "Active",
  "account": "Main_Office",
  "brand": "AcmeBackup",
  "os": "Windows_Server_2019",
  "agent_version": "26.04.15.1a2b3c4d.64",
  "last_successful_backup": "2026-10-12T02:14:09Z",
  "last_successful_backup_display": "6 hours ago",
  "stored_bytes": "48211230720",
  "stored_display": "44.9 GB",
  "retention_days": 30,
  "session_id": "1234567890123456789",
  "tran_type": "Upload",
  "stage": "completed (with errors)",
  "reported_at": "2026-10-12T02:14:09Z",
  "reported_display": "6 hours ago",
  "error_count": 2,
  "warning_count": 0,
  "messages_truncated": false,
  "messages": [
    {
      "type": "Error",
      "text": "The process cannot access the file because it is being used by another process.",
      "file": "C:\\Data\\open.pst",
      "reported_at": "2026-10-12T02:13:55Z"
    }
  ]
}

Shortened for readability; a real response includes every field listed above.

Errors and rate limits

Errors return JSON with a detail message, e.g. {"detail": "Invalid or revoked API key."}. A 400 names the field at fault instead, e.g. {"computer_status": "Must be one of: Active, Trial, Test, Suspended. Delete in the web console."}.

Rate limits

• 600 requests per hour across all endpoints, per Web Console user. All keys belonging to the same user share this limit.
• 60 requests per hour to /v1/alerts, per user, in addition to the limit above.
• 300 commands and changes per hour (POST and PATCH requests), per user, in addition to the limit above.
• After 20 failed authentication attempts in 10 minutes from one IP address, that address is blocked for 10 minutes, even with a valid key.

These limits are generous for normal monitoring: polling every 5 to 15 minutes, as described below, uses only a small share.

Tips for RMM scripts

• Poll from one machine, not every device. One scheduled script that reads /v1/endpoints (200 devices per page) or /v1/alerts covers your whole fleet in a few requests, then updates each device in your RMM. Running a script on every device that calls the API for itself uses one request per device per run, and a large fleet will soon hit the rate limit.
• Poll every 5 to 15 minutes. Status changes only as devices check in, so polling more often doesn't give fresher results.
• Match devices by computer_id, not hostname. See Identifying a device. Hostnames repeat across sites and brands.
• On a Windows device, you can get its regcode from the backup client: run your brand's client executable with -getregcode, e.g. YourBrand.exe -getregcode. It can take up to about 30 seconds, and isn't yet available on macOS. Then look the device up with ?regcode=, and store its computer_id in your RMM so later lookups need no extra step.
• Use a timeout of 30 to 60 seconds on each request, and retry later on 429 or 503.
• Don't resend a command to make sure. A 202 means it's queued; check pending_command rather than sending it again. To act on several devices, send one command per device.
• Use a read-only key for monitoring and a separate Read + write key only where your tool sends commands or makes changes.
• Older Windows can't connect. The API requires modern TLS 1.2 ciphers, which Windows Server 2012 R2, Windows Server 2008 R2, Windows 8.1 and Windows 7 don't support. Run your polling script on Windows Server 2016 or Windows 10 or later, or on macOS or Linux. Devices on older Windows are still reported; they just can't call the API themselves.
• Keep keys out of scripts. Use your RMM's secret or secure variables, and use one key per tool so you can replace one without disrupting the others.