[Feature New API] Add First-Class Subscription Management API (Lifecycle, Items, and Fulfillment Support)

[TheMadTyrant]

🌟 Describe the Feature

The GoHighLevel API currently lacks a dedicated, first-class subscription management system. Subscription functionality is tightly coupled to payments (via Stripe) and does not provide a unified or flexible way to manage subscriptions programmatically.

This feature request proposes the introduction of a comprehensive Subscription API that supports full lifecycle management (e.g., create, update, pause, resume, cancel), multi-product subscriptions, and structured access to subscription data independent of billing providers.

The goal is to enable developers to use subscriptions as core business entities—driving workflows, fulfillment, and automation—rather than treating them solely as billing artifacts.

🚀 Justification

This would be highly valuable for developers building on GoHighLevel because many modern applications rely on subscriptions as core business logic—not just billing.

Currently, developers must implement custom workarounds (external databases, Stripe syncs, custom fields, tags, and workflows) to manage subscription state and behavior. This increases complexity, introduces potential data inconsistencies, and limits scalability.

A robust Subscription API would enable developers to build:

• Subscription-based SaaS platforms
• Membership and coaching programs with lifecycle control
• Subscription box and recurring fulfillment businesses
• Healthcare and treatment plan systems with scheduled renewals
• E-commerce experiences with bundled or multi-item subscriptions

By providing a first-class subscription model, GoHighLevel would reduce reliance on external systems, simplify development, and unlock more advanced use cases—making the platform significantly more attractive for developers building scalable, production-grade applications.

📝 Suggestions

Below is a suggested structure for a first-class Subscription API:

1. Subscription Resource

   • Endpoint examples:
     • POST /subscriptions
     • GET /subscriptions/{id}
     • PUT /subscriptions/{id}
     • DELETE /subscriptions/{id}
   • Core fields:
     • contactId
     • status (active, paused, cancelled, expired)
     • startDate
     • nextRenewalDate
     • interval (days/months)
     • metadata / notes

2. Subscription Items (Multi-Product Support)

   • Endpoint examples:
     • POST /subscriptions/{id}/items
     • PUT /subscriptions/{id}/items/{itemId}
     • DELETE /subscriptions/{id}/items/{itemId}
   • Fields:
     • productId (or priceId)
     • quantity
     • unitPrice

3. Lifecycle Management Endpoints

   • POST /subscriptions/{id}/pause
   • POST /subscriptions/{id}/resume
   • POST /subscriptions/{id}/cancel
   • POST /subscriptions/{id}/expire

4. Webhooks / Events

   • subscription.created
   • subscription.updated
   • subscription.renewed
   • subscription.paused
   • subscription.cancelled

5. Relationship to Payments (Flexible Integration)

   • Allow linking to Stripe subscription IDs but do not require Stripe as the sole source of truth
   • Enable subscriptions to exist independently of payment provider when needed

6. (Optional Enhancement) Fulfillment Integration

   • Ability to associate subscriptions with orders or workflows
   • Trigger automation on renewal events (e.g., create order, send to fulfillment)

This structure would align GoHighLevel with modern API-first platforms and allow developers to build more advanced, scalable systems directly on top of GHL.

{
"subscription": {
"id": "sub_123",
"contactId": "contact_456",
"status": "active",
"startDate": "2025-01-01",
"nextRenewalDate": "2025-02-01",
"intervalDays": 30,
"currency": "USD",
"metadata": {
"notes": "Monthly plan"
},
"items": [
{
"id": "item_1",
"productId": "prod_ABC",
"name": "Testosterone",
"quantity": 1,
"unitPrice": 35.00
},
{
"id": "item_2",
"productId": "prod_DEF",
"name": "Anastrozole",
"quantity": 1,
"unitPrice": 20.00
}
]
},
"suggested_endpoints": [
{
"endpoint": "/api/v2/subscriptions",
"method": "POST",
"description": "Create a new subscription"
},
{
"endpoint": "/api/v2/subscriptions/{id}",
"method": "GET",
"description": "Retrieve subscription details"
},
{
"endpoint": "/api/v2/subscriptions/{id}",
"method": "PUT",
"description": "Update subscription"
},
{
"endpoint": "/api/v2/subscriptions/{id}/pause",
"method": "POST",
"description": "Pause subscription"
},
{
"endpoint": "/api/v2/subscriptions/{id}/resume",
"method": "POST",
"description": "Resume subscription"
},
{
"endpoint": "/api/v2/subscriptions/{id}/cancel",
"method": "POST",
"description": "Cancel subscription"
},
{
"endpoint": "/api/v2/subscriptions/{id}/items",
"method": "POST",
"description": "Add item to subscription"
}
],
"webhooks": [
"subscription.created",
"subscription.updated",
"subscription.renewed",
"subscription.paused",
"subscription.cancelled"
]
}

Product Area

ad-publishing

📋 Use Case

We are building a subscription-driven application on top of GoHighLevel where subscriptions are central to both billing and operational workflows.

We need this API to:

• Enable users to create and manage recurring subscriptions tied to contacts
• Support multiple products or bundled items within a single subscription
• Track and control subscription lifecycle states (active, paused, cancelled, expired)
• Automate downstream workflows triggered by subscription events (e.g., order creation, task automation, notifications)
• Keep subscription data reliably synced with contact records inside GoHighLevel

In our application flow:

1. A contact is created or updated in GoHighLevel
2. A subscription is assigned with one or more products or services
3. The subscription renews on a defined interval (e.g., monthly)
4. On renewal:
   • Actions are triggered (e.g., create an order, assign tasks, send notifications)
   • Billing is processed
5. Users can modify, pause, or cancel subscriptions at any time

Currently, we must manage subscription state externally and sync it back into GoHighLevel using custom fields, tags, and workflows. A dedicated Subscription API would allow us to integrate this workflow natively, reduce complexity, and improve reliability.

🚨 Why Should This Be Prioritized?

This should be prioritized because:

• It unlocks new capabilities for developers building subscription-based applications where subscriptions drive workflows—not just billing.
• It expands GoHighLevel into additional high-value use cases such as SaaS platforms, membership systems, recurring services, and fulfillment-based businesses.
• It reduces reliance on external systems (e.g., Stripe + custom databases), allowing developers to build more natively within the GHL ecosystem.
• It simplifies development and maintenance by eliminating the need for complex workarounds using custom fields, tags, and workflows to simulate subscription state.
• It improves data consistency and reliability by providing a single source of truth for subscription lifecycle and structure.
• It would save significant development time and ongoing operational overhead for teams building production-grade applications on GHL.
• Without this API, developers are forced to build and maintain parallel subscription systems, which increases complexity and limits scalability.

Overall, this feature would significantly increase developer adoption, platform stickiness, and the ability for GoHighLevel to support more advanced, scalable applications.

🧠 Additional Context

This feature would integrate well with existing GoHighLevel capabilities such as workflows, payments, contacts, and custom objects.

A first-class Subscription API could act as a trigger source for workflows (e.g., on renewal, pause, or cancellation), making automation more powerful and predictable. It would also complement the existing payments infrastructure by separating subscription lifecycle management from billing execution.

Additionally, this would align well with custom objects and future extensibility, allowing developers to build more advanced domain-specific applications directly on top of GoHighLevel without relying on external systems.

We would be happy to provide additional feedback, real-world use cases, or collaborate on API design if helpful.

[github-actions]

✅ Issue processed successfully!

Your issue has been reviewed and assigned to the appropriate team.

[i-am-rad]

Related issue... #273

[TheMadTyrant]

This is not really related, this is for the subscription API not the custom provider. I want to be able to create, update and cancel.

[i-am-rad]

It’s still related as custom providers subscriptions poorly documented. They do have similar webhook events though. So we need parity when they build out any new APIs.

[TheMadTyrant]

Any movement on this? I caught the update a few weeks back referencing issue #273 and got excited, but after digging into the custom payments integration guide I don't think it gets us where we need to be.
The BYOP integration is solid for what it is. It handles how money moves: saved payment methods, off-session charging, recurring billing webhooks. That's all useful. But that's really the payment execution layer, and what we're asking for here lives one level above that. Subscriptions as actual business entities that drive logic, not just billing artifacts.

The gaps are still very real for us. There's no dedicated subscription resource with lifecycle states, no way to pause or resume a subscription via an endpoint, no structure for multi-product subscriptions under a single record, and no subscription-driven workflow triggers like subscription.renewed firing off an automation. We also can't get at things like nextRenewalDate or intervalDays in a structured way, and everything is still tightly coupled to the payment provider rather than being able to stand on its own.

Right now we're managing subscription state externally, syncing it back into GHL through custom fields, tags, and workflows. It works, but it's fragile and doesn't scale well. Every edge case like a pause, a plan change, or a failed renewal becomes a manual process or a custom workaround.

The BYOP update overlaps with point 5 of the original proposal, the payment relationship piece, but the core ask is still wide open. A standalone Subscription API that actually drives business logic would be a meaningful unlock for a lot of what people are building on this platform. Would love to know if this is on the roadmap at all.

Sources referenced if needed:
Custom Payments Integration Docs
BYOP Changelog
Enhanced Payment Method Management