← All posts
Jul 6, 2026

Your Action1 Inventory, Automatically in Your IT Documentation

Weavestream's Action1 integration pulls Windows endpoint data — hostname, OS build, agent status, hardware — straight into client asset records, so your self-hosted IT documentation never falls behind your RMM.

If you run Action1 to patch and monitor Windows endpoints, you already have a live view of every machine’s hostname, OS build, and check-in status. The problem is that view lives in Action1 — not in the documentation your technicians actually open when a ticket comes in. So someone copies a serial number or an OS version into an asset record by hand, and by the next patch cycle it’s already wrong.

Weavestream’s Action1 integration closes that gap. It pulls endpoint records straight from your Action1 account into Weavestream asset records, on a schedule, so the inventory a technician sees in your documentation platform matches what Action1 is actually reporting.


What Action1 Is, for Anyone Documenting a Mixed Toolchain

Action1 is an endpoint management platform focused on remote monitoring and patch management for Windows endpoints. Plenty of MSPs and internal IT teams run it alongside — or instead of — a heavier RMM, specifically for patch compliance and lightweight endpoint visibility. Weavestream treats it as a first-class integration driver, not an afterthought bolted on beside NinjaOne.


What Actually Gets Synced

The Action1 driver imports endpoint records as Weavestream assets in the tenant you map the integration to. The fields it pulls cover the basics you need for day-to-day support and asset tracking, without trying to be a full RMM replacement:

  • Hostname — the machine name
  • OS version — Windows build and edition
  • Last seen — the most recent check-in timestamp
  • Agent status — online, offline, or pending
  • Hardware details — CPU, RAM, and disk

That’s a deliberately tight field set compared to something like NinjaOne’s much deeper agent-device schema. For teams whose primary use of Action1 is patch visibility and basic endpoint status, that’s the right amount of data — enough to answer “is this machine online, and what’s it running” without needing to map two dozen fields nobody looks at.


Setting It Up

  1. Navigate to Admin → Integrations → New Integration.
  2. Select Action1 as the provider.
  3. Enter your Action1 API key and organisation ID.
  4. Map the integration to the Weavestream company it belongs to.
  5. Click Save & Sync to run the initial import.

From there, syncs can be triggered manually whenever you want a fresh pull, or run automatically if background sync is enabled — so the asset record stays current without anyone remembering to re-export a CSV.


Why This Matters More Than It Looks

On its own, “hostname and OS version show up as an asset” doesn’t sound like much. The value is in where those fields land once they’re synced.

They’re scoped to the right client automatically. Because the integration maps to a specific Weavestream company, synced endpoints land directly in that client’s asset inventory — next to their credential vault, their network documentation, and their monitored domains. Nobody has to remember which spreadsheet tab belongs to which client.

They’re searchable. A synced Action1 asset is a normal Weavestream asset record, which means it’s indexed by full-text search along with everything else in that client’s workspace. Look up a hostname during a ticket and it comes back alongside the credentials and articles that reference it — not in a separate Action1 tab you have to switch to.

They’re audited. Every sync run and every field change from the Action1 driver is written to Weavestream’s audit log — the same append-only history you’d use to investigate a credential change or a manual asset edit. If an OS build or agent status changes and someone asks when, the answer is in the same place as every other change to that client’s records.

They don’t get silently deleted. Like every Weavestream integration, sync behavior is upsert-only. A machine that disappears from Action1 gets flagged as stale in Weavestream rather than removed outright, so decommissioned hardware stays in your history instead of vanishing the moment it’s retired.


One Driver Among Several

Action1 isn’t the only integration Weavestream ships with — NinjaOne, UniFi, and Cloudflare Zero Trust Lists all run through the same sync orchestration engine, each as a thin provider-specific driver on top of shared scheduling, conflict detection, and error reporting. If your stack includes Action1 for patch management and something else for network gear, both feed into the same tenant asset inventory, under the same audit trail, without you writing custom scripts to reconcile them.


The Bigger Picture

Action1 tells you what’s happening on an endpoint right now: is it online, is it patched, what hardware is it running. Documentation tells you the context around that endpoint — which client it belongs to, what credentials go with it, who’s responsible for it, what ticket history it has. Keeping those two facts in separate systems means every investigation starts with tab-switching and manual cross-referencing.

Syncing Action1 into Weavestream doesn’t replace Action1 as your patch management tool. It means the inventory Action1 already tracks accurately shows up where the rest of the client’s documentation already lives — searchable, audited, and scoped to the right tenant — without anyone maintaining a second copy by hand.


Weavestream is a free, self-hosted, open-source IT documentation platform for MSPs and IT teams. It runs on Docker and Postgres, and includes asset management, a credential vault, IPAM, domain and SSL monitoring, a client portal, audit logging, and integrations with tools like Action1, NinjaOne, UniFi, and Cloudflare. Find out more at weavestream.io.

← All posts