Skip to main content
An agent with this tool answers a networking ticket from the client’s Datto Networking data: is the access point or switch down, since when, and did a reboot bring it back. With no ticket, it audits every site’s devices and subscriptions.
Automatically enabled when you configure Datto Networking permissions in your agent workflow. No manual toggle needed.

​
What It Does

  • Find the client’s networks from the Organization Mapping. A client with several sites has one network per site
  • Read a network’s access points, switches and power strips: online or down, last check-in, uptime, model, MAC address, serial, firmware, IP, subscription (active, start and end date, term) and end-of-sale and end-of-life dates
  • Read traffic history per network, device and WiFi client, and site survey results
  • Reboot an access point, switch or power strip, reset a switch or power strip port, upgrade firmware now, or re-pair a device
  • Add, move or remove a device; change network, switch and power strip settings
  • Block, unblock and name WiFi clients, and create, renew or delete guest vouchers
  • Create and delete networks and network groups, and manage portal users and their access
The agent calls Datto Networking through the Vendor API tool, with datto_networking as the vendor id. Sandbox scripts can call Datto Networking too, under the same permissions.

​
Permission Groups

A reboot, a port reset and the other device actions are sent as reads by Datto’s API, but Neo treats them as changes: they follow the group’s approval setting, and a read-only agent or script cannot send them.

​
Access Profiles

Every group Read Only. The agent can look up any network, device, history or client, but never changes anything.
Creates guest vouchers and blocks or names WiFi clients on its own. Every other change, reboots included, waits on a technician.
Reboots devices, resets ports, edits devices, and manages WiFi clients and vouchers on its own. Device Inventory, Network Settings, Networks & Network Groups and Users & Account changes wait on a technician.
Nothing waits on a technician, except the changes below.

​
Changes that always ask a technician

These always wait on a technician, whatever the settings: deleting a network or a network group, changing a portal user’s password, changing the account owner, accepting Datto’s service agreement, and any write whose body sets a value on a field whose name contains password, secret, passphrase, psk or community, or is token, key or pdt_key.

​
Ticket runs stay on the client’s networks

On a run for a ticket, Neo sends only calls that name a network mapped to the ticket’s company. A call on one device (node/<id>, switch/<id>, powerstrip/<id>) carries the network in Neo’s network_id parameter, and Neo checks that the device is on that network before it sends the call. Calls that reach every client (the network list and search, the MAC lookup, network groups, users and the account) and moving a device from another network run only without a ticket, for example in a scheduled agent or a chat.

​
Not available through Neo

Neo refuses these before it calls Datto Networking:
  • Logging in with a user’s email and password, and creating API keys, because the response is a working key and secret
  • Deleting the calling user’s own API keys, because one of them is the key Neo signs with. The agent can delete another user’s keys
  • Creating a password reset token, because the response is a credential. The user resets their password from the portal’s sign-in page
Neo also replaces the value of every such field (by the same name rule) in each Datto Networking response before an agent or a script sees it, and the old and new values of such a field in the audit log. A change that sends that placeholder back is refused.

​
Setup

See Connecting Datto Networking to Neo.