Current + Axcient x360Recover integration

Axcient x360Recover is where a lot of MSPs keep the whole continuity estate: the appliances on partner sites, the vaults they replicate into, and every protected server and workstation behind them. Current's Axcient integration is a view-only feed into the strategic business review module and the company alert band. It reads what Axcient already knows and never writes back.

What the integration does

Current authenticates to Axcient with an API key created in x360Portal, walks your client list, protected systems, appliances and vaults every six hours, and stages the result as evidence for AI-assisted business reviews. Instead of exporting a protected-systems list the week of the review, the backup numbers are already sitting on the company record when you open it.

What data flows

• Partners — the Axcient client roster, matched to your Current companies so every signal below lands on the right record, with the appliance, Direct-to-Cloud and cloud-archive protected-system counts split by servers and workstations.
• Protected systems — each machine with its type, protection model, operating system, agent version, Axcient's health verdict and the reason behind it.
• Restore points — the last local backup, the last private-vault replication and the last cloud replication, tracked separately because which ones exist depends on how the system is protected.
• Boot verification — whether the last AutoVerify run judged the system bootable, when it finished, and which recovery point it used.
• Backup jobs — how many jobs each system runs and how many Axcient currently reports unhealthy.
• Storage — local, vault and cloud bytes per system and per partner.
• Appliances and vaults — reachability, health, software version and storage for your own infrastructure.

The feed is one-way. Current does not run restores, start virtualizations, trigger failover, deploy or remove agents, change schedules or retention, or touch alerting thresholds. Those endpoints are not in the connector's code, so they cannot be reached by a bug either. Two Axcient calls are worth naming because they are the ones that would matter — one changes how long a vault may be unreachable before Axcient warns you, and one mints a new agent enrolment token. Both are excluded by name. Axcient stays the source of truth for management; Current uses the evidence.

Unknown reads as unknown

A system Axcient has no boot-verification record for shows as unknown in Current, not as failed — that feature is optional, and its absence says nothing about whether the machine would boot. A health word the connector does not recognize is likewise unknown rather than a pass or a failure. That distinction matters in a review: a backup number built by treating silence as success is a number you cannot defend when a partner asks which machines it covers.

One definition of a failing backup

A protected system counts as failing when Axcient's own health reads Troubled or Unprotected, or its most recent restore point is more than three days old, or its last boot verification failed and that run is itself stale. The same definition drives the company card, the alert and the dashboard tile, so they cannot disagree. Warned is a caution rather than a miss. Parked — Axcient's word for a partner you have deliberately suspended — is not counted as a failure at all, because a paused backup is a decision rather than a fault.

Alerts that clear themselves

Axcient joins the same backups-failing alert as every other backup source Current reads, so a company raises one alert whichever tool saw the problem rather than one per product. The alert clears itself when the count returns to zero on a complete run. Account managers see open problems, not a scrolling log of everything that ever failed.

Matching clients to companies

Each Axcient client is one end-customer. Current links clients to companies by normalized name — punctuation and Inc/LLC/Ltd-style suffixes stripped — and only when exactly one company matches. Where two companies could both be the answer, the client stays on an unmapped list for a person to decide rather than being paired on a guess. Axcient carries no link back to your PSA, so each client's short code is shown beside its name to help tell two similar ones apart. A mapping set by hand is never overwritten by a later automatic match, and mapping a client attaches its systems immediately instead of waiting for the next scheduled sync.

Your infrastructure stays yours

A vault serves every partner you back up, so it never attaches to one company record — vault reachability and storage live on the integration card instead. Appliances belong to a site and do attach to the mapped company. Either way, one of your boxes being unreachable is never counted as an alert on a partner's endpoints.

Where the data appears

• In strategic business reviews, in the backup and continuity chapter alongside your other backup feeds such as Veeam.
• On the company record, where the backup section shows protected systems and how many are failing, the protection mix, the most recent restore point, boot-verification results and storage.
• In dashboard backup metrics, including protected systems and systems failing.
• In the company alert band, as a backups-failing entry that reflects what is failing now.

Why it matters

The backup section is where most business reviews go vague, because the evidence lives in the BDR platform and the review lives somewhere else. An MSP running Axcient for a partner like Northwind Traders can open the account and see nineteen protected systems with one failing, that thirteen of them are Direct-to-Cloud and six still run through the on-site appliance, when the newest restore point was taken, which machines boot-verified this week, and how much storage the account is consuming — without anyone assembling an export first. The Direct-to-Cloud split is the number that starts a modernization conversation; the failing count is the one that ends an argument.