I’m currently building a ServiceM8 app and had a question around app deactivation / uninstall behaviour.
I may have missed this in the documentation, but I can’t find any reference to whether a payload is sent to an app’s callback URL when a user deactivates or uninstalls an app from within ServiceM8.
Specifically, I’m trying to understand:
When an app is deactivated or uninstalled, is any event or payload sent to the app’s callback URL?
If so, what information is included (e.g. Vendor ID, location ID, app ID, timestamp)?
If not, is there a recommended pattern for detecting that an app has been removed?
The reason for asking is around data lifecycle and compliance.
If a user removes the app in ServiceM8, I’d like to be able to automatically clean up or delete any app-specific user data on my end. Without an uninstall/deactivation signal, the only alternative seems to be asking users to separately request deletion from our own platform.
Happy to be pointed to existing docs if this is already covered — and thanks in advance for any clarification.
There’s no dedicated uninstall/deactivation event that sends a payload to your callback URL (the SDK docs describe callbacks being invoked for Action events and manifest webhooks).
When an add-on is deactivated, the OAuth access token and refresh token will be revoked, so this is a pretty good signal the add-on has been deactivated.
Yes that is how im currently managing it. But it would be nice to be absolute incase credetials are revoked but the app was not deactived (for some reason)
For Add-on SDK web-service hosted add-ons, ServiceM8 invokes your callback URL when a user performs an Action you’ve configured in your manifest, and for events generated via the manifest webhooks (UI clicks or subscribed record field changes).
When ServiceM8 does invoke your add-on, the documented event payload includes identifiers like auth.accountUUID (the ServiceM8 account UUID) and auth.staffUUID (the staff member UUID).
In the current Add-on SDK docs, we only describe callback invocations for Action events and webhook events, and don’t describe a separate “add-on deactivated/uninstalled” event being POSTed to your callback URL.
What we do document is that a user can revoke access to a connected application by disabling the add-on from within the ServiceM8 Add-on Store, and that the Account Activity log records an “Add-on activated/deactivated” entry.
If you need a definitive confirmation of the current deactivation/uninstall signalling behaviour for your add-on type, email support@servicem8.com with a link to this post and your App ID, and we’ll confirm what’s available.
