# 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).