claudetools/projects/msp-tools/research/2026-06-16-syncro-api-rmm-policy-capabilities.md

Syncro API — RMM / Policy Management capabilities (research)

• Date: 2026-06-16
• By: Mike (GURU-5070) + Claude
• Question: Does the Syncro (SyncroMSP) public REST API expose the RMM side of the product — specifically policy management (push AV like Bitdefender, manage monitors/ scripts/patch policies, assign policies to assets)?
• Status: Research only — NOT yet folded into the /syncro skill (per Mike). Verify token scope before relying on /policy_folders.

TL;DR

No — RMM policy management is NOT exposed by the Syncro API. The API exposes the policy folder hierarchy (organizational only) plus read-only RMM inventory (assets, patch status, installed apps) and RMM alerts. There is no endpoint to run scripts, send remote commands, start a remote session, deploy software, install patches, or edit a policy's content (monitors/ scripts/patch schedule/AV). Those are UI-/agent-only. (This is exactly the gap GuruRMM fills, and why a Bitdefender push goes through the Syncro UI/policy, not the API.)

Method (authoritative)

Endpoint probing alone was misleading (guessed wrong path names → false 404s). The definitive source is Syncro's own OpenAPI 3.0.0 spec:

• Docs UI: https://api-docs.syncromsp.com/ (Swagger UI)
• Raw spec: https://api-docs.syncromsp.com/swagger.json (~470 KB) — read this, not the UI.
• Live probes against https://computerguru.syncromsp.com/api/v1 confirmed behavior + the 401.

(Grok live-web pass returned empty — its known finalization quirk; the published spec is authoritative anyway, so no second-model opinion was needed.)

The ENTIRE RMM surface in the spec

Searching all paths in swagger.json for polic/script/rmm/run/command/remote/agent/patch/install returns exactly:

Path	Methods	Notes
/policy_folders, /policy_folders/{id}	GET, POST, PUT, DELETE	folder hierarchy only (see below)
/customer_assets, /{id}	GET, POST, PUT	RMM-managed devices (asset_type: "Syncro Device")
/customer_assets/{id}/patches	GET	Windows patch data (read) — works (200)
/customer_assets/{id}/installed_applications	GET	installed apps (read) — works (200)
/rmm_alerts, /{id}, /{id}/mute	GET, POST, mute, DELETE	RMM alert read/create/mute/clear

That is the whole list. No /scripts, no run-script, no /remote_sessions, no agent/command endpoint exists anywhere in the spec.

The decisive detail — /policy_folders is organization, not policy content

POST /policy_folders request body accepts only three fields:

customer_id   # which customer the folder belongs to
name          # folder name
parent_id     # parent folder (for nesting)

So you can create/rename/nest/delete the policy-folder tree and tie a folder to a customer — but there is no field for the policy's content (monitors, scripts, patch schedule, AV/ Bitdefender), and no way to assign a policy to an asset via the API. RMM policy definition and assignment remain UI-only.

Gotcha — token scope

GET /policy_folders returned HTTP 401 with the same API token that returns 200 for assets/patches/alerts → the endpoint exists but the token lacks the policy permission scope. Enable it per-token in Syncro Admin → API Tokens before even the folder CRUD will work.

What you CAN automate against Syncro RMM today

• Read asset inventory, Windows patch status, and installed applications per device (reporting, drift detection, "who's missing patch X").
• RMM alerts: list / create / mute / clear.
• Policy folders: create/rename/nest/delete (e.g. auto-create a folder per new customer) — after enabling the token's policy scope.

What you CANNOT (must use the Syncro UI / agent, or GuruRMM)

• Run scripts / send remote commands / open remote sessions on agents.
• Deploy software (e.g. Bitdefender), trigger patch installs, reboot.
• Create/edit policy content (monitors, scripts, patch policy, AV) or assign policies to assets.

Next steps (if we want to act on this)

• Decide whether to enable the policy scope on a dedicated token and script the folder hierarchy.
• For programmatic endpoint actions (scripts/commands/deploy), route through GuruRMM, not Syncro.
• Fold the API-capability boundary into the /syncro skill once reviewed (Mike: hold for now).