How to Set Up the GoHighLevel New SaaS Plan Created Webhook

What the New SaaS Plan Created webhook does

This GoHighLevel event is designed to notify an external endpoint when a new SaaS plan is created in the agency’s SaaS configuration. The notification is normally delivered as a JSON request using HTTP POST. The receiving application can then inspect the event and decide whether to create, update or route information elsewhere.

The event should be treated as a business-state change: a plan has moved from not existing to existing in GoHighLevel. That distinction matters because downstream systems should respond to the creation event rather than repeatedly polling GoHighLevel or relying on a person to copy plan information into another tool.

Possible uses include synchronizing a plan catalog, creating a corresponding product in a billing process, notifying an operations team, updating internal documentation or sending structured data into a reporting pipeline. The correct use depends on the next decision your business needs to make.

Decide what should happen before configuring the webhook

Start by writing the intended outcome in one sentence. For example: “When a new SaaS plan is created, create a review task and add the plan to the internal catalog.” This is more useful than beginning with a tool or an endpoint because it identifies the business action that the integration is meant to support.

Then answer four operational questions:

• What system should receive the event?
• Which fields are required for the next action?
• Who owns the workflow if the request fails or the data is incomplete?
• What should happen if the same event is delivered more than once?

If these questions cannot be answered, the webhook may be technically connected but operationally unclear. A successful HTTP response does not prove that the downstream process created the correct record or that a person will notice a failed transformation.

Prepare the receiving endpoint

GoHighLevel needs a destination that can accept an HTTPS POST request and process JSON. This may be a custom application, an integration platform, an internal service or a controlled webhook receiver used for testing. The endpoint should acknowledge the request quickly and move longer processing into a separate job where appropriate.

Before using a production URL, confirm the following:

• The endpoint accepts POST requests over HTTPS.
• The receiver can read and log the raw request body safely.
• The request can be authenticated using an agreed secret, token or other verification method supported by the integration design.
• The receiver returns an appropriate success response after the request has been accepted.
• Logs include enough context to identify the event without exposing sensitive information unnecessarily.
• The workflow has a retry and failure path that someone owns.

A request inspector can be useful during initial testing, but it should not become the permanent production destination for SaaS plan data. Move to a controlled receiver once the payload and expected behavior are understood.

Configure the GoHighLevel webhook

The labels and navigation may change as GoHighLevel updates its interface, but the configuration logic remains consistent. Work at the agency level because the event concerns SaaS plans rather than an individual sub-account.

The name of the webhook should help an operator understand its purpose months later. Naming it only “SaaS webhook” makes troubleshooting harder when several events or destinations exist.

Test the event with a controlled SaaS plan

Testing should verify more than whether a request arrived. It should confirm that the correct event was emitted, the payload can be parsed, the receiver responds correctly and the downstream action is safe to repeat.

1. Create a temporary SaaS plan with a recognizable test name.
2. Watch the receiver logs or request inspector for the incoming POST request.
3. Save the raw payload in a controlled location for mapping and troubleshooting.
4. Identify the plan identifier, plan name, timestamps and other fields actually supplied in the request.
5. Confirm that the receiver returns the expected success response.
6. Check whether the intended downstream record or task was created correctly.

Do not assume that fields mentioned in a general description will have exactly the same names, nesting or data types in every version of the event. Build the mapping from an observed payload and verify it against the current GoHighLevel documentation before relying on it in production.

Design the receiver for duplicate and failed deliveries

Webhook delivery is not the same as guaranteed business completion. A sender may retry a request, a network connection may fail after processing has started, or an operator may replay an event during troubleshooting. The receiving workflow should therefore be idempotent.

In practical terms, idempotency means that processing the same event more than once does not create multiple billing records, duplicate tasks or conflicting catalog entries. Use a stable event or plan identifier as a deduplication key where the available data supports it. Store the processing status and retain enough information to investigate a failed attempt.

Separate acceptance from processing when the work is substantial. The endpoint can validate the request, store the event and return a success response, while a worker performs the longer transformation. This makes the receiver easier to monitor and reduces the chance that a slow downstream system causes avoidable delivery failures.

Define what happens when required information is absent. A useful failure path may place the event in a review queue, alert an owner or mark the record as needing attention. Silently discarding an incomplete plan creates a data gap that may not be discovered until reporting or billing is already affected.

Map the payload to a business process

Payload mapping should be documented as a business rule rather than left inside an unmaintained automation step. For every field used by the receiver, record its source, destination, data type, whether it is required and what should happen when it is absent.

For example, a plan identifier might be used as the external key for a catalog record, while a plan name might be displayed to an operator. Pricing or billing information may require validation before it is sent to another system. A creation timestamp may be useful for audit history but should not automatically be treated as the time a plan became commercially active unless that meaning is explicitly defined.

This distinction prevents a common systems problem: copying fields successfully without agreeing on what those fields mean. A connected process can still produce unreliable reporting if one system interprets a plan as created, another as active and a third as ready for sale.

Use the event in a wider automation architecture

Once the core webhook is stable, connect it to the smallest useful next action. If the workflow needs several routing rules, validation steps or application connections, an integration service such as Zapier Automation may help coordinate the work. If the webhook is part of a broader customer or sales operating model, review the ownership, data model and reporting requirements through a structured CRM consulting process.

A sensible sequence is:

1. Receive and authenticate the event.
2. Validate the minimum required fields.
3. Deduplicate using a stable identifier.
4. Create or update the target record.
5. Assign ownership for any manual review.
6. Record the result and expose failures through a usable report or alert.

Do not add AI merely because the workflow contains unstructured information. This event is usually structured enough for deterministic rules. AI may have a defined role later, such as summarizing exception details for an operator, but it should not replace clear creation, validation or ownership logic.

ConsultEvoClient Work: Automation, CRM and Operations SystemsExamples of connected systems designed around operational problems, data and workflow reliability.→

Production checklist

What good looks like

A well-designed GoHighLevel SaaS plan webhook does more than send data to another URL. It creates a controlled handoff between a plan creation event and a clearly defined operational outcome. The receiver knows what the event means, which fields matter, how to handle repeats and who investigates exceptions.

That process-first approach keeps the integration maintainable as more SaaS plans, tools and reporting requirements are added. More connections are not automatically a better operating system. The useful measure is whether the workflow reduces manual updates, preserves clean ownership and gives people trustworthy visibility into what happened.