Source: ai-research/ghl-2026-05-01/support-solutions-articles-155000006586-marketplace-app-uninstall-api.md

The Marketplace App Uninstall API lets a Marketplace app developer programmatically remove their own app from a user account — typically a dormant or inactive sub-account — without waiting for the user to do it manually. The motivation is performance and cost: every installed instance generates webhook traffic, and dormant accounts produce traffic with no upside. The API is a hygiene primitive for keeping the active install footprint lean.

Key Takeaways

  • What it does. Programmatically uninstalls the developer’s own app from a target user account. The official Public API documentation is at Uninstall an application.
  • Primary motivation: webhook hygiene. Dormant installs generate redundant webhook events. Uninstalling them reduces webhook noise, lowers processing cost, and improves latency for active accounts.
  • Auth requirement. Valid HighLevel API credentials for the developer app. The exact scope is documented at the linked Public API page.
  • Identify-then-uninstall pattern. The standard workflow is (1) use your own analytics/database to identify dormant accounts, then (2) call the uninstall endpoint per account, optionally as a scheduled batch job.
  • Verifiable side-effect. After uninstalling, webhook activity from the affected account stops. Use webhook logs to confirm the uninstall took effect.
  • Forward-compatible with webhook-subscription controls. GHL has signaled future per-account webhook subscription APIs (referenced as Q4 enhancements in the source) that will give finer-grained control without full uninstallation.

Capability Summary

The Public API documentation page is the canonical reference for the exact endpoint path, payload, and response. The support article emphasizes the why (cost, latency, cleanup) and the workflow (auth → identify → call → verify → automate) more than the wire format itself.

The five-step setup the support article documents:

  1. Authentication. Verify you have valid API credentials authorized to call the uninstall endpoint for your app.
  2. Identify Dormant Accounts. Use your app’s analytics or database to pinpoint inactive user accounts that warrant uninstallation. (Definition of “dormant” is left to the developer — common signals are zero API calls in N days, no logins, or zero webhook responses received.)
  3. Call the API Endpoint. POST to the uninstall endpoint per the Public API documentation.
  4. Monitor Webhook Activity. Confirm webhook events from the uninstalled account cease — that’s the durable proof the call took effect.
  5. Automate. Wire the uninstall into routine maintenance scripts so dormant-account cleanup runs without operator intervention.

Use Cases

  • Offboarding flows. A user cancels their plan with you (the app developer) — uninstall the app from their sub-account immediately rather than leaving a zombie install.
  • License revocation. Subscription expired, payment failed, or terms-of-service violation triggers automatic uninstall.
  • Automated cleanup of dormant accounts. Sub-accounts with no activity in 90+ days get uninstalled to reduce webhook noise.
  • Cost optimization. When webhook processing costs are tied to install count, periodic dormant-account cleanup directly reduces infrastructure spend.
  • Bulk migrations. Moving a sub-account to a different version of the app (uninstall old, prompt fresh install of new).

Open Questions

The exact endpoint path, HTTP method, payload shape, and response format are documented at the linked Public API documentation but were not duplicated in the support article body captured here. Consult the Public API page for production implementation.

Try It

  1. Define what “dormant” means for your app: e.g., zero API calls in 60 days, zero webhook deliveries acknowledged in 30 days, or no login by the user in 90 days.
  2. Build a query in your analytics store that returns the list of sub-account IDs meeting that definition.
  3. Read the Public API uninstall documentation for the exact endpoint path and payload schema.
  4. Implement a one-shot uninstall script. Test it on a single development sub-account and verify webhook activity from that account stops.
  5. Schedule the script as a routine maintenance job (daily, weekly, or monthly depending on your dormancy threshold).
  6. Track the metric “active installs / total ever installed” — uninstalling dormants should improve this ratio without losing real users.