Post a Kaseya VSA 10 device notification
Short answer
Paste the VSA 10 server, a token id, a token secret, and the device id. A confirmed outage posts a device notification. It does not run a script.
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 Kaseya VSA 10. Early access. Feedback welcome. VSA 10 is a different product from Kaseya VSA 9. The server, the token, and the device id do not match a VSA 9 agent.
On Pro or Business, open the client, then Alerting, then Remote monitoring, and choose Kaseya VSA 10. Paste the server address, the token id, the token secret, and the device id. Leave the checkbox off until one device notification looks right on that device.
Leave the organization id, the agent id, the ticket form, the ticket status, and the two-factor box blank. Those fields belong to the other remote-monitoring choices. A confirmed outage posts one device notification. Recovery posts a second one. Nothing is closed, and no script is run.
What you create in VSA 10
The VSA 10 API guide says the API is REST and OData. List fields use PascalCase. Lists can be paged. Public documentation is at the VSA X reference. While you are logged in, the same reference is on your own server at /api, for example https://exampleserver.vsax.net/api.
The calls go to that server, https://<server>.vsax.net. api.vsax.net is the public reference. It is not the server you paste. The form accepts a public https host that is one name plus .vsax.net, such as https://yourserver.vsax.net. A VSA 9 host, a private address, and api.vsax.net are rejected.
Third-party tokens are the access a customer uses. The guide says to open Configuration, then API Access, then Third-Party Tokens, and choose Create Token. The token can have a start date, an end date, an IP allow list, a limit to some organizations, and a limit to some API endpoints. When you create it, copy the token id and the token secret. The guide says the secret is shown then and is not shown again after you accept. Watchbill stores both encrypted. Leave Access id and Access secret blank on a later save to keep them. Paste a new pair only when you rotate the token.
Every request uses Basic authentication. The header is the token id, a colon, and the token secret, encoded as Base64. The guide says a request that is not HTTPS fails. There is no login step and no session token. That is different from VSA 9, which calls GET /auth and then sends a bearer token. Do not paste a VSA 9 username or personal access token into these two fields.
What gets posted
Notify, on the VSA X reference, creates a device notification. The request is POST https://<server_name>/api/v3/notifications. The body fields on that page are InstanceId, Title, Message, and Priority. InstanceId is required and is described as the identifier of the instance that triggered the notification, at most 100 characters. Title is required and is what the push notification shows. Message is optional, appears in the notification detail, defaults to the title, and is at most 5000 characters. Priority is optional. The parameter table lists Low, Normal, Elevated, and Critical, and says the default is Normal. The curl sample on the same page uses lowercase critical. This form sends the table values: Critical when the outage opens, and Normal when the check recovers. Whether a live server accepts that casing was not checked here.
The device id you paste is sent as InstanceId. Get a Specific Device calls the route value the device identifier, and the sample is a GUID such as 11111111-2222-3333-4444-555555555555. The response field is Identifier. Publish Device uses InstanceId for a unique instance identifier, and that sample is a GUID of the same shape. The reference does not print one sentence that says those two names are always the same value on an installed agent. Use the device identifier from the VSA 10 device, not a VSA 9 agent id. A VSA 9 agent id is digits. This form accepts only a GUID. Confirm one notification on a test device before you enable more clients.
The message starts with [Watchbill], says the check is down or back up, and includes the check URL and the status URL. Open and recovery are two notifications. The first one is not edited, and it is not deleted. Delete a Specific Notification is on the reference. This path does not call it.
Organization ids on Get All Devices are integers, and they are not the numeric organization ids from VSA 9. Notify does not take an organization id, so the form does not ask for one. Leave that box blank.
What is not called
The reference includes Run Workflow, Run Task, and Run Script. Those paths are refused before a request is sent. Move a Device, Publish Device, and the custom-field write endpoints are not called either. A failed minute does not send. A maintenance window does not send. The trigger is a confirmed outage, which means both regions agreed, and the matching recovery.
The token secret is not written into the notification, the page, or the logs. A 401 or a 403 is a bad credential or a missing permission on that token. Five terminal failures turn the connection off. HTTP 429 is retried, and a Retry-After header is honored.
Limits that were on the pages
The API guide and the reference do not print the same Notify limit. The guide says Notify supports 10 requests per 5 seconds, 50 requests per minute, 200 requests per 5 minutes, 500 requests per hour, and 2,000 requests per day. The Notify section of the reference says 3600 requests per hour. Both pages were read on 12 October 2026. This path does not add a second throttle of its own. It retries HTTP 429.
The same guide lists failed-request limits per IP address, and it says those limits were changing in Q3 2024. The reference describes a sliding window, HTTP 429, and failed-request headers. Which of those windows a tenant enforces today was not measured from here.
Most other endpoints on the guide support 3,600 requests per hour. Get a Group Package is tighter. This path does not call that endpoint.
Turn it on for one client
The checkbox is off until you check it. Each client has its own server, token, and device id. There is no account-wide VSA 10 switch. If the notification never appears, confirm the host ends in .vsax.net, the token is a third-party token from Configuration > API Access, and the device id is the GUID from that device. Then look at notifications on the device. The VSA 9 agent note is a different screen, in Kaseya VSA 9. Ticket email for a PSA is a different screen too.
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 token secret. It does not delete notifications already in VSA 10.
How The Watchbill helps
On Pro and Business, Kaseya VSA 10 can post a device notification when a confirmed outage opens and when it closes. It stays off until that client turns it on. It posts a notification. It does not run scripts, and it does not close anything in VSA. The token id and token secret are the third-party token from the VSA 10 API guide. Early access. Feedback welcome.