Add Datto RMM site notes for outages
Short answer
Paste a Datto API URL, an API key, an API secret, and the site uid. A confirmed outage appends one site note. It does not start a quick job.
How The Watchbill helps
- A check runs about once a minute.
- Email goes out when a check is down and when it recovers.
- Each client can have a status page that stays private until you publish it.
This guide is what to paste for Datto RMM, which permissions the key has, and the write limits on Datto's API page.
On Pro or Business, open the client, then Alerting, then Remote monitoring, and choose Datto RMM. Paste the site uid, one of the six API hosts below, the API key, and the API secret. Confirm the note on that site before you enable more clients.
Leave device id, agent id, and the two-factor box blank. Leave the checkbox off until one site note looks right. A confirmed outage appends to the site notes. It does not start a quick job.
What you create in Datto
The API v2 page, read 12 October 2026, says keys are generated per user under Setup, after API access is enabled. The key's permissions are that user's API security level. The count of keys is per Datto account, not per user. Use a user whose API security level can read and update the site. The Watchbill does not hold a separate Datto partner credential.
The token URL is {API URL}/auth/oauth/token. The page's Postman steps name client id public-client and client secret public, sent as Basic auth. The token example uses grant_type=password with the API key as the username and the API secret as the password. Access tokens expire after 100 hours. A new token is requested when a note is sent.
Which host to paste
The API v2 page names these hosts. Another host is rejected.
| Platform | API host |
|---|---|
| Pinotage | pinotage-api.centrastage.net |
| Merlot | merlot-api.centrastage.net |
| Concord | concord-api.centrastage.net |
| Vidal | vidal-api.centrastage.net |
| Zinfandel | zinfandel-api.centrastage.net |
| Syrah | syrah-api.centrastage.net |
Paste https:// plus the host for your platform. The site uid is the id Datto shows for that site. It is not the site's display name.
What gets written
The same page says POST /v2/site/{siteUid} accepts name, description, notes, onDemand, and splashtopAutoInstall, and that a field left out of that POST is cleared. The call used here is GET then POST on /api/v2/site/{siteUid}. It reads the site and sends those fields back with the note appended. If name is not a string, or onDemand or splashtopAutoInstall is not a boolean, it does not POST. A partial POST can clear those fields, so a missing boolean is a stop, not a guess.
Whether a live GET always returns those two flags as booleans is the help page's POST example, not a separate GET schema. Requests to the six hosts for the OpenAPI URL on that page returned HTTP 500 on 12 October 2026, so the field list is from the help page. If your platform's GET omits a boolean that is actually true, the note will not be written. Confirm one site before you enable the rest.
Activity logs on that page are GET /v2/activity-logs only. Quick jobs exist in the API. This path does not call them. Job paths are refused before the request is sent. The note text starts with [Watchbill], names the check, and includes the status URL. If that outage's marker is already in the notes, it does not POST again.
Rate limits on that page
The API v2 page says 600 query requests in the past 60 seconds, and 100 write requests in the past 60 seconds by default. At 90 percent of the quota the response is delayed by one second. Over the limit, HTTP 429 until the count drops. The page says to wait 60 seconds. Persistent requests after that can return HTTP 403 and block the calling IP for about 5 minutes. A Datto 403 is retried for at least 300 seconds. A 401 is a bad credential and is not treated as that block. Five terminal failures turn the connection off.
One open and one recovery are two writes, minutes apart, which is inside the 100-write window for a single client. A large burst of sites going down together can still hit it. The retry is the backoff, not a tighter loop.
Turn it on for one client
The checkbox is off until you check it. Each client stores its own site uid and key. There is no account-wide Datto switch. The trigger is a confirmed outage open and the matching recovery. A maintenance window does not send. The key and secret are stored encrypted. Leave them blank on a later save to keep the stored secret.
If the note never appears, confirm the host is one of the six, the site uid matches, and the user's API security level can update sites. Then check that the GET returned the two booleans. A failed write that would have cleared onDemand or Splashtop is skipped on purpose.
What the screen shows
Before a row is saved, the line says Off. A saved connection with the checkbox clear stays Off. With the checkbox on, it says On. After failed attempts it says Off after failed attempts and shows the count. Remove deletes that client's connection and the stored key. It does not clear the site notes already written in Datto. Those notes stay until someone edits them there.
The appended text starts with [Watchbill], names the check, and includes the status URL and a marker. If that marker is already in the notes, the site is not posted again. The other site fields are sent back only when the GET returned a name and the two booleans. That is the guard against clearing on-demand or Splashtop. If a test note does not appear, read the site in Datto before you assume the key is wrong. A skipped write looks like a failure and is safer than a cleared flag.
How The Watchbill helps
On Pro and Business, Datto RMM can append a site note when a confirmed outage opens and when it closes. It stays off until that client turns it on. It posts a note. It does not run jobs. A PSA mailbox is a separate card, in ticket email.