Related research: [[index]], [[control-surface-inventory]], [[high-value-management-angles]], [[wrapper-gaps-and-direct-api-candidates]], [[implementation-vs-doc-status]] ## Project Summary The answer is **yes**: Synology exposes real, useful management control surfaces through `synology-api`; this is not just an observability wrapper. The practical control plane is strongest in **identity and policy**, **storage and data movement**, **platform lifecycle**, **certificates**, and **Surveillance Station**. A second important finding is that some of the most interesting domains are **implemented upstream but underdocumented**, especially **Docker / Container Manager** and **Virtualization / VMM**. The real thin spots are elsewhere: **Drive Admin write paths, KeyManager, Log Center write operations, OAuth lifecycle management, and several network/security namespaces**.[^api-index][^docs-status][^core-user][^core-package][^docker-source][^virtualization][^drive-admin][^oauth] ## Executive Answer If the question is **“what actual control surfaces do I have?”**, the answer is: 1. **Already usable now through the wrapper**: users, groups, quotas, share permissions, shared folders, packages, task scheduling, event scheduling, power scheduling, FileStation, Download Station, Cloud Sync, certificates, and Surveillance Station.[^core-user][^core-group][^core-share][^core-package][^task-scheduler][^event-scheduler][^filestation][^downloadstation][^cloudsync][^certificate-source][^surveillance] 2. **Likely usable, but source-driven because docs lag**: Docker / Container Manager, Virtualization / VMM, and some source-verified system and snapshot/replication operations.[^docs-status][^docker-source][^virtualization][^snapshot][^core-sysinfo] 3. **Still weak or read-only in the wrapper**: Drive Admin write paths, KeyManager, Log Center writes, OAuth lifecycle control, Note Station CRUD, NFS service/export control, and much of the network/security namespace family.[^drive-admin][^docs-status][^log-center][^oauth][^notestation][^nfs-sysinfo][^core-service-apps-source][^vpn][^dhcp][^security-advisor] That means Synology’s management API story is materially stronger than “observability plus a few toggles,” but weaker than “everything in DSM is cleanly wrapped and documented.” ## The Most Valuable Control Surfaces ### 1. Identity and policy governance This is one of the strongest and most immediately useful surfaces in the whole wrapper: - local user CRUD - local group CRUD - group membership changes - password policy and expiry controls - share permissions, quotas, and bandwidth rules[^core-user][^core-group][^core-share] This is the right layer for onboarding/offboarding, storage governance, and access-hardening automation. ### 2. Storage and data movement This is where Synology looks especially operationally mature: - shared folder lifecycle, encryption, and permissions - FileStation upload/copy/move/delete/compress/extract/share-link flows - Download Station task lifecycle and scheduling - Cloud Sync connection, task, filter, and schedule control[^core-share][^filestation][^downloadstation][^cloudsync] This is not passive monitoring. It is policy, movement, placement, and external sharing control. NFS deserves a narrower mention. The wrapper can read top-level NFS service status via `SYNO.Core.FileServ.NFS`, and upstream source also exposes one undocumented `fileserv_nfs_advanced_set(**kwargs)` path plus getter-only access to per-share export rules under `SYNO.Core.FileServ.NFS.SharePrivilege`. That makes NFS an **indirect and source-driven** surface rather than a first-class wrapper-confirmed control plane for service enablement or export-rule management.[^nfs-sysinfo][^core-service-apps-source] ### 3. Platform lifecycle and orchestration Package Center, Task Scheduler, Event Scheduler, and power schedules combine into a native orchestration layer: - install / upgrade / uninstall packages - create and run scheduled scripts - create bootup/shutdown-triggered tasks - set physical power-on / power-off schedules[^core-package][^task-scheduler][^event-scheduler] This is one of the most powerful domains in the wrapper and also one of the easiest to misuse. ### 4. Certificates Certificates are narrower than storage or scheduling, but they are an especially strong **automation first pick** because the workflow is clean and high value: - list certificates - upload or replace a certificate - set a default certificate - assign a certificate to a specific service - export certificate material[^certificate-source] This is one of the clearest places where Synology API automation delivers real operational value quickly. ### 5. Surveillance Station Surveillance Station is a first-class control plane in its own right: - provision and update cameras - enable/disable cameras - PTZ operations and presets - motion/tamper/input tuning - recording and event lifecycle operations[^surveillance] If your NAS is acting as a surveillance appliance, this belongs in the top tier of usable control surfaces. ## Important Correction from the Review Pass One of the most important changes from the initial sweep is that **Docker / Container Manager is not a wrapper gap**. The upstream docs-status tracker marks Docker as `finished`, and the Docker source file explicitly says it provides full coverage of all 12 `SYNO.Docker.*` namespaces, including container lifecycle, image management, network management, compose project create/update/start/stop/delete/build, registry management, and related utilities.[^docs-status][^docker-source] The broader lesson is that **documentation status is not the same thing as implementation depth**: - Docker is source-strong and docs-supported. - FileStation and Surveillance Station are implementation-rich even where docs remain `partial`. - Virtualization is source-present even though docs status is `not_started`.[^implementation-note] This distinction matters because otherwise the report would understate the most useful control surfaces. ## Implemented but Underdocumented Control Domains These are not “missing” features. They are best thought of as **source-driven capability lanes**. | Domain | Why it matters | Caveat | | --- | --- | --- | | Docker / Container Manager | Full workload lifecycle: containers, images, networks, registries, compose projects.[^docker-source] | Trust should come from source + focused testing, not just docs headlines. | | Virtualization / VMM | VM, task, storage, network, host, and image operations exist upstream.[^virtualization] | Public docs status is `not_started`, so this is source-first territory. | | SysInfo write surface | Even a mostly read-heavy class still includes shutdown/reboot and selected hardware controls.[^core-sysinfo] | High blast radius, limited but important write surface. | | Snapshot / replication surfaces | Snapshot and replication operations appear materially useful for pre-change safety and DR sync workflows.[^snapshot] | Some docs are partial or broken; source inspection is still important. | ## Where the Wrapper Is Actually Thin These are the areas where “direct DSM API candidate” is the right framing. | Domain | Current wrapper reality | Why it matters | | --- | --- | --- | | Drive Admin | Mostly read-heavy; `index_pause` is the standout action.[^drive-admin] | Good candidate for raw `SYNO.SynologyDrive.*` exploration. | | KeyManager | Upstream tracker still marks key-management subdomains as `not_started`.[^docs-status] | Critical if encrypted-share key automation matters. | | Log Center writes | Wrapper is inspection-heavy, not configuration-heavy.[^log-center] | Limits syslog routing and retention automation. | | OAuth lifecycle | Clients, tokens, and logs are listed, but no client CRUD or revocation.[^oauth] | Prevents real token/client management. | | Note Station CRUD | Read-only inspection in the wrapper.[^notestation] | Less central for admin work, but still a genuine limitation. | | NFS service and export control | Top-level service status is read-only; one undocumented advanced-settings write path exists upstream; per-share NFS export rules are getter-only.[^nfs-sysinfo][^core-service-apps-source] | Important if you need NFS service toggles or host/squash rule automation, but not a structured wrapper-ready admin surface. | | VPN / DHCP / Security Advisor write paths | Current wrapper documentation is mostly getters.[^vpn][^dhcp][^security-advisor] | Easy to over-credit because the namespaces sound stronger than the surfaced methods. | ## Best Automation Priorities ### Priority 1 — Certificate rotation This is the cleanest quick win. It is high value, operationally meaningful, and structurally clear in the wrapper.[^certificate-source] ### Priority 2 — Identity and storage governance If you care about “real administration,” user/group/share/ACL/quota automation is where the wrapper is already strong and trustworthy.[^core-user][^core-group][^core-share] ### Priority 3 — Data movement workflows FileStation, Download Station, and Cloud Sync together enable practical workflows around ingest, staging, placement, throttling, and controlled external sharing.[^filestation][^downloadstation][^cloudsync] ### Priority 4 — Packages and schedulers These give you a genuine lifecycle and orchestration layer, but only if you treat them as privileged and potentially destructive.[^core-package][^task-scheduler][^event-scheduler] ### Priority 5 — Docker and VMM, if your NAS runs workloads These are now strong candidates for a second wave of work, but the right posture is source-driven validation, not casual assumption.[^docker-source][^virtualization] ## High-Risk Surfaces That Need Guardrails | Surface | Why it is risky | Guardrail | | --- | --- | --- | | Task Scheduler / Event Scheduler | Can create persistent or privileged execution paths, including root-like scripts and boot/shutdown tasks.[^task-scheduler][^event-scheduler] | Require explicit approval and high-signal logging. | | Shutdown / reboot | Immediate platform outage.[^core-sysinfo] | Never make these ambient or automatic. | | Share permission and encryption changes | Can lock users out or alter data availability.[^core-share] | Require target verification and rollback planning. | | Package uninstall / upgrade | Service disruption or unexpected behavior change.[^core-package] | Use maintenance windows and pre-change snapshots/backups. | | Recording / snapshot deletion | Irreversible data loss.[^surveillance][^snapshot] | Require confirmation gates and dry-run listing first. | | Container / VM lifecycle on live workloads | Service interruption and state risk.[^docker-source][^virtualization] | Prefer graceful operations and explicit scope selection. | ## Final Position Synology’s API control story is stronger than it first appears. The real picture is: - **not just observability** - **not universal, cleanly documented admin control either** - **but absolutely enough real control to automate meaningful NAS management today** If you start from the wrapper-confirmed domains — identity, shares, FileStation, Download Station, Cloud Sync, packages, schedulers, certificates, and Surveillance Station — you already have a substantial management plane. Then, if your use case needs it, you can expand into the source-driven but underdocumented domains like Docker and VMM. Only after that should you spend time on direct DSM reverse engineering for the genuine write-side gaps.[^control-inventory-note][^gaps-note][^implementation-note] [^api-index]: Synology API class index: https://n4s4.github.io/synology-api/docs/apis [^docs-status]: Upstream documentation status tracker: https://github.com/N4S4/synology-api/blob/master/docs_status.yaml [^core-user]: Core User docs: https://n4s4.github.io/synology-api/docs/apis/classes/core_user [^core-group]: Core Group docs: https://n4s4.github.io/synology-api/docs/apis/classes/core_group [^core-share]: Core Share docs: https://n4s4.github.io/synology-api/docs/apis/classes/core_share [^core-package]: Core Package docs: https://n4s4.github.io/synology-api/docs/apis/classes/core_package [^task-scheduler]: Task Scheduler docs: https://n4s4.github.io/synology-api/docs/apis/classes/task_scheduler [^event-scheduler]: Event Scheduler docs: https://n4s4.github.io/synology-api/docs/apis/classes/event_scheduler [^certificate-source]: Certificate source entrypoint: https://github.com/N4S4/synology-api/blob/master/synology_api/core_certificate.py [^docker-source]: Docker source entrypoint: https://github.com/N4S4/synology-api/blob/master/synology_api/docker_api.py [^virtualization]: Virtualization source entrypoint: https://github.com/N4S4/synology-api/blob/master/synology_api/virtualization.py [^filestation]: FileStation docs: https://n4s4.github.io/synology-api/docs/apis/classes/filestation [^downloadstation]: Download Station docs: https://n4s4.github.io/synology-api/docs/apis/classes/downloadstation [^cloudsync]: Cloud Sync docs: https://n4s4.github.io/synology-api/docs/apis/classes/cloud_sync [^surveillance]: Surveillance Station docs: https://n4s4.github.io/synology-api/docs/apis/classes/surveillancestation [^core-sysinfo]: Core SysInfo docs: https://n4s4.github.io/synology-api/docs/apis/classes/core_sys_info [^snapshot]: Snapshot docs: https://n4s4.github.io/synology-api/docs/apis/classes/snapshot [^drive-admin]: Drive Admin Console docs: https://n4s4.github.io/synology-api/docs/apis/classes/drive_admin_console [^log-center]: Log Center docs: https://n4s4.github.io/synology-api/docs/apis/classes/log_center [^oauth]: OAuth docs: https://n4s4.github.io/synology-api/docs/apis/classes/oauth [^notestation]: Note Station docs: https://n4s4.github.io/synology-api/docs/apis/classes/notestation [^nfs-sysinfo]: Core SysInfo docs (`fileserv_nfs`): https://n4s4.github.io/synology-api/docs/apis/classes/core_sys_info [^core-service-apps-source]: CoreServiceApps source entrypoint, including NFS advanced-setting and share-privilege helpers: https://github.com/N4S4/synology-api/blob/master/synology_api/core_service_apps.py [^vpn]: VPN docs: https://n4s4.github.io/synology-api/docs/apis/classes/vpn [^dhcp]: DHCP Server docs: https://n4s4.github.io/synology-api/docs/apis/classes/dhcp_server [^security-advisor]: Security Advisor docs: https://n4s4.github.io/synology-api/docs/apis/classes/security_advisor [^control-inventory-note]: Supporting note: [[control-surface-inventory]] [^gaps-note]: Supporting note: [[wrapper-gaps-and-direct-api-candidates]] [^implementation-note]: Supporting note: [[implementation-vs-doc-status]]