Axcient x360Recover
Your whole BCDR footprint, answerable in plain English.
Axcient x360Recover is your backup and disaster-recovery layer, and the honest answer to "are we actually protected?" is normally a tour through x360Portal — client by client, device by device, appliance by appliance. Connect it here and a session reads the whole estate at once: which devices last backed up and when, what AutoVerify actually proved about last night's boot test, and — the question a console alone can't answer — which endpoints your RMM knows about that x360Recover has never heard from. Fifteen capabilities, every one of them a read. The x360Recover public API has no write endpoints, and this agent registers none.
The story
What changes once it’s connected.
x360Portal is built to be looked at, not queried, so a real estate check is a lot of clicking: open a client, open a device, open its restore points, repeat. Connect x360Recover here and the same ground gets covered in a sentence — which devices have failed or skipped a backup, what the latest recovery points look like for a given machine, whether last night's AutoVerify boot test actually passed and what its screenshot shows, and which appliances or cloud vaults are worth a second look.
The coverage follows how a BCDR book is actually organized. Clients and the devices registered under them. Devices themselves, filterable by client, by health state, by Direct-to-Cloud versus appliance-protected, and by device type, plus the full detail and restore-point history behind any one of them. AutoVerify results with the evidence attached — the boot-verification screenshots that turn "it says green" into something you can actually look at. Appliances and cloud vaults, read individually or across the book.
Then the part a console genuinely can't do on its own: reconciling x360Recover against the rest of the stack. A backup health summary rolls the whole estate up into one pass — protected, stale, failing. A stale-backups check flags anything that hasn't completed successfully inside 24 hours or 7 days, whichever the ask calls for. And an unprotected check joins x360Recover's device list against the Asio RMM endpoint roster — by asio_endpoint_id where a client has that mapping, falling back to a hostname match where it doesn't — to surface the machines RMM can see that x360Recover has no record of at all, which is the coverage gap a per-client tour never catches.
Things you can ask
Ask it like you’d ask a teammate.
Skills included
Every skill, in the open.
15 skills across 6 areas
Read-only, and structurally so: the x360Recover public API exposes no write endpoints, and this agent registers none — there is no tool anywhere in the surface that can start a backup, kick off a restore, edit a device, or touch an appliance or vault's configuration. The credential is a partner API key generated in x360Portal (Settings → API Keys); it carries whatever partner-level visibility that key holds, and every call runs under it.
Agent & session1What this connection is and whether it's answering — the first thing to check when a result looks wrong.⊘ Read-only, and it reports the connection rather than repairing it — it cannot mint a fresh key or swap which partner account is bound. A rotated or revoked x360Portal API key shows up here as a connection that has stopped validating.›
whoamiWhat this session is wired to and whether the stored API key is still validating.
Estate & clients3The client roster under the partner account, and the devices registered under each one.⊘ Reading only — no client is added, renamed, or removed, and no device is registered or deregistered from here.›
list_clientsEvery client under the partner account, with the ids the rest of this surface asks for.get_clientOne client's record opened in full, pulled straight by its client id.list_client_devicesThe devices registered under a single client — the roster a per-client health check starts from.
Devices & restore points3The protected machines themselves — filterable by client, health, Direct-to-Cloud versus appliance-protected, and device type — plus their restore-point history.⊘ Read-only. No backup job is started, paused, or cancelled, and no device setting is changed from here.›
list_devicesDevices across the book, filterable by client, health state, D2C vs. appliance protection, and device type.get_deviceOne device's full record, looked up on its own.get_restore_pointsA device's recovery-point history — what's actually recoverable, and as of when.
AutoVerify & evidence1The boot-verification record — not just a pass/fail flag, but the screenshot behind it.⊘ Reads the result AutoVerify already produced; it does not trigger a new verification run.›
get_autoverifyAutoVerify's boot-verification result for a device, screenshots included, so "it passed" can actually be checked.
Appliances & vaults4The BCDR hardware and cloud storage behind the devices — read individually or across the book.⊘ Read-only — no appliance is rebooted or reconfigured, and no vault setting is changed from here.›
list_appliancesEvery appliance under the partner account, with its status.get_applianceOne appliance's record in full, including how current its firmware and software are.list_vaultsEvery cloud vault under the partner account.get_vaultOne vault's record opened on its own.
Health rollups & coverage3Estate-wide answers built on top of the per-device reads: overall backup health, what's gone stale, and — by reconciling against the Asio RMM roster — what isn't protected at all.⊘ Reads and reconciles; it changes nothing. The RMM cross-check joins on asio_endpoint_id where a client has that mapping recorded, and falls back to a hostname match where it doesn't — an honest best-effort join, not a guaranteed one, so a hostname collision or a machine renamed on one side and not the other can miss.›
backup_health_summaryThe whole estate rolled up in one pass — protected, stale, and failing, client by client.stale_backupsDevices with no successful backup inside a 24-hour or 7-day window, whichever the ask calls for.unprotected_checkx360Recover's device list joined against the Asio RMM endpoint roster — by asio_endpoint_id, with a hostname-join fallback — to surface machines RMM knows about that x360Recover doesn't.
Connecting
Wire it in, in an afternoon.
How to connect
- 01Sign in to x360Portal (partner.axcient.com) and open Settings → API Keys.
- 02Create (or regenerate) an API key for the x360Recover public API.
- 03Paste it here — the connection is validated live before anything saves.
Related
Keep patching the board.
Patch your stack in.
Start the Switchboard free trial against your own environment — read-only, traced answers, live in an afternoon. The apps are on the shelf when you want them.