[GH-ISSUE #538] ConnectWise Manage Ticketing integration

kerem commented

2026-02-25 23:42:17 +03:00

Owner

Originally created by @jameskirsop on GitHub (Jun 29, 2021).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/538

We would like low priority alerts to become tickets in our ConnectWise Manage instance.

I'm happy to write this integration, but ConnectWise require a clientID Authorization header to be passed.

Whilst I could use my employers clientId internally, for wider inclusion of the integration, it would be required for this project to sign up for the ConnectWise Developer program, apply for a Vendor clientID and then use that in the integration - rather than using a 'partner' clientId that's unique to a particular ConnectWise partner.

@cuu508, are you able to go through this registration process as the owner of the project? I'll get to work on writing an integration.

Originally created by @jameskirsop on GitHub (Jun 29, 2021). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/538 We would like low priority alerts to become tickets in our ConnectWise Manage instance. I'm happy to write this integration, but ConnectWise require a `clientID` Authorization header to be passed. Whilst I could use my employers clientId internally, for wider inclusion of the integration, it would be required for this project to [sign up for the ConnectWise Developer program](https://register.developer.connectwise.com), [apply for a Vendor clientID](https://developer.connectwise.com/ClientID/Vendor_Client_IDs) and then use that in the integration - rather than using a 'partner' clientId that's unique to a particular ConnectWise partner. @cuu508, are you able to go through this registration process as the owner of the project? I'll get to work on writing an integration.

kerem closed this issue

2026-02-25 23:42:17 +03:00

kerem commented

2026-02-25 23:42:17 +03:00

Author

Owner

@jameskirsop commented on GitHub (Jul 6, 2021):

There's an initial commit for a working implementation here: github.com/jameskirsop/healthchecks@05cbf5136b

Some things still to do include:

Complete the documentation with screen shots
Add the Manage icon to the font set so it's rendered on the Checks and individual check page - I'm not sure if we have a build process for this???

For us to be able to close/resolve a Manage ticket on a Check UP event, we'll need some way of internally storing the ticket ID. Unfortunately, unlike the OpsGenie integration (for example) we can't pass a known alias to both the create and update events. For us to be able to update an existing ticket, we must pass the ticket ID - and so that would need to be stored alongside the check/notification record.

I'd thought that storing this on the 'Notification' object would be ideal, but to be able to get this for the UP event would require a database lookup to get the last 'DOWN' notification and retrieve the ticket ID. We would also have to reengineer the HTTPTransport._request method to pull out the JSON response from the Manage API.

@jameskirsop commented on GitHub (Jul 6, 2021): There's an initial commit for a working implementation here: https://github.com/jameskirsop/healthchecks/commit/05cbf5136bff595dae555fa995ee2bec9cdc4728 Some things still to do include: - Complete the documentation with screen shots - Add the Manage icon to the font set so it's rendered on the Checks and individual check page - I'm not sure if we have a build process for this??? For us to be able to close/resolve a Manage ticket on a Check UP event, we'll need some way of internally storing the ticket ID. Unfortunately, unlike the OpsGenie integration (for example) we can't pass a known alias to both the create and update events. For us to be able to update an existing ticket, we must pass the ticket ID - and so that would need to be stored alongside the check/notification record. I'd thought that storing this on the 'Notification' object would be ideal, but to be able to get this for the UP event would require a database lookup to get the last 'DOWN' notification and retrieve the ticket ID. We would also have to reengineer the `HTTPTransport._request` method to pull out the JSON response from the Manage API.

kerem commented

2026-02-25 23:42:17 +03:00

Author

Owner

@cuu508 commented on GitHub (Jul 6, 2021):

I haven't yet had a chance to look into getting a vendor clientID, but wanted to add a quick comment about handling ticket IDs.

The Notification object is probably the right place to put the ticket ID. But there may be another viable option – when creating a ticket, store the check's code somewhere (a custom field?). When resolving a ticket, first use "Get Tickets" or "Ticket Search" API call to look up the ticket ID.

I did something similar a while ago when I was working on a Zendesk integration:

github.com/healthchecks/healthchecks@a869906fde (diff-09216d7e52)

(in the end I abandoned the Zendesk integration, because I could not get the UX right, but this part at least did work OK)

@cuu508 commented on GitHub (Jul 6, 2021): I haven't yet had a chance to look into getting a vendor clientID, but wanted to add a quick comment about handling ticket IDs. The Notification object is probably the right place to put the ticket ID. But there may be another viable option – when creating a ticket, store the check's code somewhere (a custom field?). When resolving a ticket, first use "Get Tickets" or "Ticket Search" API call to look up the ticket ID. I did something similar a while ago when I was working on a Zendesk integration: https://github.com/healthchecks/healthchecks/commit/a869906fde99c67483ebc243e62aafb0a24ff999#diff-09216d7e52d9ea25534c3d3d9f6516ed7e4bb873736169a7c99b005901d8049cR391 (in the end I abandoned the Zendesk integration, because I could not get the UX right, but this part at least did work OK)

kerem commented

2026-02-25 23:42:17 +03:00

Author

Owner

@jameskirsop commented on GitHub (Jul 8, 2021):

Thanks @cuu508, I've taken some of your workflow concepts from the Zendesk integration and incorporated it into an updated commit on my branch that uses a custom field in Manage to store the UUID and updated the appropriate documentation (still needs screen shots).

Could you take a look at the diff and see if you're happy to include the integration as it stands? If so, I'll put some time into tidying up the documentation, improving the UI/UX a little more and writing some tests before doing a PR.

@jameskirsop commented on GitHub (Jul 8, 2021): Thanks @cuu508, I've taken some of your workflow concepts from the Zendesk integration and incorporated it into an updated commit on my branch that uses a custom field in Manage to store the UUID and updated the appropriate documentation (still needs screen shots). Could you take a look at [the diff](https://github.com/healthchecks/healthchecks/compare/master...jameskirsop:connectwise-integration) and see if you're happy to include the integration as it stands? If so, I'll put some time into tidying up the documentation, improving the UI/UX a little more and writing some tests before doing a PR.

kerem commented

2026-02-25 23:42:18 +03:00

Author

Owner

@cuu508 commented on GitHub (Jul 8, 2021):

Looks good overall, I have a few minor suggestions mainly around code organization:

In notify() the tickets base URL gets constructed multiple times. I would move it to a variable and reuse
notify() is long and does multiple things – I would move the ticket id lookup code into a separate _get_ticket_id() method
in Channel class, there are a few new properties to get ConnectWise configuration. May be cleaner to have one property (e.g. connectiwisemanage_conf) that returns a dictionary
there's one hardcoded clientId value left in the code
for requests.get, requests.patch etc. calls, add timeout=10 to prevent this from blocking too long

@cuu508 commented on GitHub (Jul 8, 2021): Looks good overall, I have a few minor suggestions mainly around code organization: * In `notify()` the tickets base URL gets constructed multiple times. I would move it to a variable and reuse * `notify()` is long and does multiple things – I would move the ticket id lookup code into a separate `_get_ticket_id()` method * in Channel class, there are a few new properties to get ConnectWise configuration. May be cleaner to have one property (e.g. `connectiwisemanage_conf`) that returns a dictionary * there's one hardcoded clientId value left in the code * for `requests.get`, `requests.patch` etc. calls, add `timeout=10` to prevent this from blocking too long

kerem commented

2026-02-25 23:42:18 +03:00

Author

Owner

@cuu508 commented on GitHub (Jul 8, 2021):

I found several points in ConnectWise Developer program's ToS that I object to. Looks like without developer account I cannot access their API documentation, create client id, or get access to a test instance.

To merge any code in Healthchecks, I would want to personally test it, and be able to test and maintain it in he future. I would recommend to maintain this integration in a fork. I would reconsider merging it if there was specific interest from multiple paying or would-be-paying customers.

@cuu508 commented on GitHub (Jul 8, 2021): I found several points in ConnectWise Developer program's ToS that I object to. Looks like without developer account I cannot access their API documentation, create client id, or get access to a test instance. To merge any code in Healthchecks, I would want to personally test it, and be able to test and maintain it in he future. I would recommend to maintain this integration in a fork. I would reconsider merging it if there was specific interest from multiple paying or would-be-paying customers.

kerem commented

2026-02-25 23:42:18 +03:00

Author

Owner

@jameskirsop commented on GitHub (Jul 8, 2021):

Thanks for that feedback, I've made the changes requested.

Maintaining a fork is less than ideal - having to regularly rebase to maintain a single feature seems like a lot of work.

Would you mind sending me a list of issues you have with the ToS? I'd like to try and remove any roadblocks that prevent this feature merged into the project and raise your issues with our account manager and the Manage platform team (I doubt I'll get anywhere, but at least I can know I've tried). My email address is on my profile.

@jameskirsop commented on GitHub (Jul 8, 2021): Thanks for that feedback, I've made the changes requested. Maintaining a fork is less than ideal - having to regularly rebase to maintain a single feature seems like a lot of work. Would you mind sending me a list of issues you have with the ToS? I'd like to try and remove any roadblocks that prevent this feature merged into the project and raise your issues with our account manager and the Manage platform team (I doubt I'll get anywhere, but at least I can know I've tried). My email address is on my profile.

Rows
Columns

[GH-ISSUE #538] ConnectWise Manage Ticketing integration #393