Most integrations sync data to make a tool more convenient. The Breeze integration exists for a blunter reason: if Breeze goes down, gets ransomed, or your team loses access to it during an incident, you still need to know what devices exist, what subnets they sit on, what backup schedules were configured, and what automations were running. That information shouldn’t live in exactly one place.
Weavestream’s Breeze integration is a read-only reconstruction sync. It pulls durable, non-secret facts out of Breeze’s Partner API and writes them into native Weavestream records — assets, IPAM subnets, and versioned articles — so the documentation your team relies on during an outage doesn’t depend on Breeze being reachable.
What “Reconstruction” Actually Means
This isn’t a mirror or a live dashboard. Weavestream doesn’t install an agent, doesn’t copy monitoring state, doesn’t run commands, and never writes back to Breeze. It reads a defined set of durable facts — device identity, inventory, network topology, configuration policies, backup schedules, custom fields — and stores them as ordinary Weavestream data.
That distinction matters for what gets left out on purpose. Online/offline state, heartbeat telemetry, health scores, alerts, patch posture, vulnerabilities, agent tokens, remote-access state, and job logs are all excluded. Those are operational signals that belong in a monitoring tool. What Weavestream keeps are the facts you’d need to rebuild an understanding of a client’s environment from scratch: what hardware exists, how it’s networked, what policies govern it, and what the documented recovery procedure is.
The result — the company’s asset records, IPAM subnets, and reconstruction articles — remains fully usable in Weavestream even if Breeze is completely offline. That’s the point.
Least-Privilege by Design
Setting up the integration means creating a dedicated read-only service principal in Breeze, not reusing an existing API key or a human account’s JWT. Weavestream requests exactly eight read scopes — organizations, sites, devices, inventory, configuration, scripts, backup-configuration, and custom-fields — and documents what each one is used for.
If you don’t need a resource, you can omit its scope entirely and leave that resource disabled on the Weavestream side. No listed scope grants remote access, command execution, secret reads, user management, or administrative write access. For an MSP that has to answer questions from a client’s security team about exactly what a third-party integration can see and do, “read-only, eight named scopes, no write path” is a much easier conversation than “full API access.”
The credential itself is encrypted at rest with a key-tagged envelope, and the masked value in the UI is never refilled as plaintext — so even someone with admin access to the Weavestream instance can’t casually read the key back out.
Built to Resist SSRF, Not Just Trust the URL
Every outbound request the integration makes runs through Weavestream’s SSRF and DNS-rebinding guard. Private, loopback, link-local, and metadata-endpoint destinations are blocked by default, DNS is resolved and pinned per request, and a redirect gets revalidated rather than treated as an automatic pass. If your Breeze deployment is intentionally private, you explicitly allowlist its CIDR range rather than disabling the guard wholesale.
This is the kind of detail that’s easy to skip in a first integration and expensive to retrofit later. An integration layer that fetches attacker-influenced URLs on a schedule is a textbook SSRF surface, and Weavestream treats it that way from the start rather than treating the guard as optional hardening.
Secrets Don’t Make It Into the Dossier
Custom fields and configuration data can contain accidental secrets — an API key pasted into a note field, a password left in a script comment. Breeze reconstruction has an explicit secret_blocked state for exactly this case: if Weavestream detects secret-like material in a value it would otherwise store, it refuses to write it and records the fact that something was withheld, without ever persisting the rejected value anywhere — not in a gap report, not in a log, not in an audit row.
That’s a meaningfully different posture than “we’ll sync whatever’s there.” It means the reconstruction dossier can be exported, printed, or handed to an incident responder without a manual review pass to scrub secrets that shouldn’t have synced in the first place.
Ownership Rules That Respect Manual Edits
Sync tools have a well-known failure mode: they overwrite a technician’s manual correction on the next run. Breeze reconstruction avoids this with three explicit ownership rules configured per field mapping:
- Source wins — Breeze is authoritative; every sync updates the field.
- Preserve manual — Breeze populates the field until a human edits it locally, then the manual value sticks.
- Manual only — sync never touches the field at all.
Only an exact match on integration, organization mapping, resource, company, and target field can mutate a value — sync can’t claim a manually created asset, note, or article it doesn’t explicitly own. If a technician has already documented something more accurately than Breeze has it, that documentation survives the next sync.
Nothing Gets Deleted Out From Under You
When a full traversal no longer sees a device or subnet that Breeze previously reported, Weavestream doesn’t delete the corresponding record — it marks the binding stale and soft-archives it, while preserving history, provenance, and any manually added content. If the device reappears in a later sync, the same record is restored rather than duplicated.
Every lifecycle event — created, updated, marked stale, restored, or blocked — writes an audit row with bounded, non-sensitive detail. Raw source payloads, credentials, and rejected secret values are never included. That gives you a defensible record of what changed and when, without turning the audit log into a second place secrets could leak from.
Setting It Up
- In Breeze, go to Settings → Service Principals and create a read-only partner principal scoped to only the resources you plan to enable. Capture the one-time API key.
- In Weavestream, go to Admin → Integrations → New Integration, choose Breeze RMM, and enter your Breeze URL (just the origin — no path, credentials, or query string) and the key.
- Click Test connection. A
401points to a key, expiry, or principal problem; a403means an enabled resource is missing its exact scope. - Open Organizations and explicitly map each Breeze organization to the Weavestream company it belongs to. Anything left unmapped is never written.
- Choose Dry run first if you want to see what a traversal would do without committing any changes — it fetches, validates, and reports, then rolls everything back.
- Run a full sync, then check the completeness view for any Missing or Secret blocked entries that need attention.
Sync can run on a schedule (every 15 minutes by default, configurable per integration) or on demand. Scheduled runs pick incremental or full automatically based on your last successful checkpoint, so you’re not manually deciding which mode to run.
Why This Belongs in a Disaster Recovery Conversation
Every MSP documentation strategy eventually runs into the same question: what happens when the tool you depend on for documentation is itself unavailable? A live dashboard synced from a PSA is only as resilient as the PSA. A read-only reconstruction that lands in your own self-hosted Postgres database, with its own backup and restore process, is a different kind of resilience — the kind that’s still there during the incident that made you need it.
Weavestream’s normal backup/restore process covers the reconstructed data along with everything else: back up the database and the deployment’s secret material, and after a restore you re-test the connection, run a dry-run full traversal, and verify a company export before resuming the normal schedule. It’s disaster recovery documentation that’s designed to be recovered itself.
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 NinjaOne, Action1, UniFi, Cloudflare, and Breeze. Find out more at weavestream.io.