> ## Documentation Index > Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt > Use this file to discover all available pages before exploring further. # Domotz API > Read Domotz collectors, devices, history and alerts, edit devices, resolve alerts, manage monitoring, Organizations and users, and power cycle a device through its switch port or PDU — each area follows the approval setting you give it An agent with this tool answers a network ticket from the client's Domotz data: is the whole site down or one device, when the device dropped off, and whether a power cycle brought it back. Automatically enabled when you configure Domotz permissions in your agent workflow. No manual toggle needed. ## What It Does * Find the client's collectors from the [Organization Mapping](/integrations/domotz/overview#your-clients-are-mapped-automatically). A client with several sites has one collector per site * Read a collector's devices with their status, uptime, latency and history, and the site's speed tests, IP conflicts and network topology * Read device metrics, sensors, activity logs and the account audit log * Edit a device's details (name, type, model, vendor, importance, room, zone, serial, notes) and its inventory values; tag it, add a sensor or an external host, and start a configuration backup * Read alert events with the rules, profiles and contact channels behind them, and resolve an alert once the device is back * Change what Domotz watches: alert rules and their bindings, excluded and hidden devices, monitoring state * Power a device on, off or through a cycle on its PoE switch port or PDU outlet, reboot it, or run a custom driver action * Change a collector's scan policies and routed networks, close a VPN session, and manage Organizations, their contacts and the account's users The agent calls Domotz through the [Vendor API](/agents/tools/vendor-api) tool, with `domotz` as the vendor id. [Sandbox](/agents/tools/built-in/sandbox) scripts can call Domotz too, under the same permissions. ## Permission Groups | Group | Access levels | What it covers | | - | - | - | | **Collectors & Devices** | Disabled, Read Only, Read/Write | Collectors and their devices: status, uptime, latency, speed tests, IP conflicts, topology, history, metrics, sensors, activity and audit logs, device profiles. Write edits a device's details (name, type, model, vendor, importance, room, zone, serial, notes) and inventory values, tags a device, adds sensors, triggers and external hosts, starts or uploads a configuration backup, names an outlet and attaches a device to it, sets device credentials and SNMP settings, and applies a device profile | | **Collector Settings** | Disabled, Read Only, Read/Write | How a collector discovers and reaches the network: scan and interface policies, DHCP discovery, routed networks, service ports, the collector's default SNMP credentials, VPN sessions (list and close), moving a collector to another team, and deleting a collector | | **Monitoring Coverage** | Disabled, Read Only, Read/Write | Alert rules (create and change) and their bindings to collectors, devices and contact channels, alert profile bindings, excluded and hidden devices, monitoring state (managed or unmanaged), and deleting a device, sensor or trigger | | **Alerts** | Disabled, Read Only, Read/Write | Alert events, alert rules and profiles, contact channels. Write resolves an alert | | **Device Actions** | Disabled, Read Only, Read/Write | Power on, off or cycle through a PoE switch port or PDU outlet, software reboot, PDU outlet actions, running and binding custom drivers | | **Organizations** | Disabled, Read Only, Read/Write | The Domotz Organizations, which collectors belong to each, and their contacts. Write creates, changes and deletes them | | **Users & Account** | Disabled, Read Only, Read/Write | Domotz users, user groups and roles, areas and teams, and the account's tag and inventory field definitions | A write in **Monitoring Coverage** can stop an alert without anyone noticing: a hidden or unmanaged device, or an unbound alert rule, raises nothing. A write in **Collector Settings** or **Users & Account** can change what a collector finds or who reaches the account. Each is a separate group so you can ask for approval on those writes alone. ## Access Profiles Every group Read Only. The agent can look up any collector, device, history or alert, but never changes anything. Resolves alerts on its own. Every other change waits on a technician. Changes devices, runs power actions, resolves alerts and manages Organizations on its own. Monitoring Coverage, Collector Settings and Users & Account changes wait on a technician. Nothing waits on a technician, except the two operations below. Two operations always wait on a technician, whatever the settings: deleting a collector, which removes the site and its whole history, and deleting an Organization. ## Not available through Neo Neo refuses these before it calls Domotz: * Opening a remote connection to a device or a collector VPN session, because the response is a working access link or VPN configuration * The text of a stored device configuration, which can contain passwords. The agent reads the backup list and its checksums, to see when a configuration changed * Camera snapshots, because the response is an image the agent cannot read * Bulk deleting a collector's offline devices, because the call names no device. The agent can delete devices one at a time * Wiping the account's whole inventory, which deletes every field and value on every device Neo also removes SNMP community strings and keys from every Domotz response before an agent or a script sees it. ## Setup See [Connecting Domotz to Neo](/integrations/domotz/connecting-to-neo). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.