Overview
This integration sends payment data from Whop into a GoHighLevel (GHL) workflow as soon as a purchase is made. A Whop webhook fires on payment success, GHL receives it via an Inbound Webhook trigger, and you can create or update contacts, apply tags, grant course access, send emails or SMS, and route customers into different automations based on what they bought in Whop.
Setup has three parts: create the Whop webhook, build the GHL workflow to receive and map the data, and add conditional logic to route contacts by product or plan.
Part 1: Create the webhook in Whop
Step 1 — Access the Developer tab
- Log into your Whop dashboard and scroll to Developer in the left sidebar.
- If you don’t see Developer, you need Owner-level permissions. Ask your account owner to update your role — you can’t create webhooks without it.
- In Developer, click Webhooks.
- Click Create a Webhook.
The Developer tab is only visible to users with Owner permissions. If it’s missing, contact your account admin before continuing.
Step 2 — Choose your webhook event
Whop supports several webhook events. Start with Payment Succeeded — it’s the main one for tracking new customers in GHL. Use a separate webhook and separate GHL workflow for each event so automations stay easy to debug.
| Event type | Priority | When to use |
|---|
| Payment Succeeded | Start here | Fires when a customer completes a payment. Use to create/update contacts and run post-purchase automation. |
| Payment Failed | Secondary | Fires when a payment attempt fails. Use for follow-up or retry reminders. |
| Dispute Created | Secondary | Fires when a customer opens a dispute. Use to alert your team or pause access. |
| Refund | Secondary | Fires when a refund is issued. Use to update contact status, remove tags, or revoke access. |
Create one webhook and one GHL workflow per event type. Mixing multiple events into one workflow makes troubleshooting and maintenance much harder.
Part 2: Set up the GoHighLevel workflow
Step 3 — Create the Inbound Webhook trigger
- In GoHighLevel, go to Automation and create a new workflow from scratch.
- Add a trigger and select Inbound Webhook.
- Copy the unique webhook URL GHL generates for this workflow.
- In Whop, paste that URL into the webhook Destination field, choose Payment Succeeded as the event, and click Save.
Step 4 — Send a test payload
- Right after saving the webhook in Whop, click Test on the webhook to send a sample payload to GHL.
- In your GHL workflow, click Fetch Sample Request.
- GHL will show the incoming payload. Select the first sample.
- You’ll see all fields Whop sends: email, name, billing info, product details, payment method, membership ID, and more.
- Label your trigger clearly (e.g., “Whop — Payment Succeeded”) so you can find and edit it later.
Always test right after creating the webhook. GHL needs at least one sample payload before you can map fields. Without it, the field selector stays empty and you can’t use Whop data in actions or conditions.
- Add a Create/Update Contact action after the Inbound Webhook trigger.
- Email: Click the tag icon → Inbound Webhook Trigger → User → email. This maps the customer’s email from the Whop payload.
- Full Name: Click the tag icon → Inbound Webhook Trigger → Data → Billing (name is here because Whop collects it on paid purchases) → select the name field.
- Optionally map phone, address, or custom GHL fields. They’re under Inbound Webhook Trigger → Data.
Name comes from the Billing section of the payload, not the top-level user object. Whop only requires name and address when a payment is processed. Free sign-ups may not include this data.
Whop payload field reference
Use these fields for contact mapping or conditional logic:
| Field | GHL path | Description |
|---|
| email | Inbound Webhook → User → email | Customer email. Primary identifier in GHL. |
| name | Inbound Webhook → Data → Billing → name | Full name from billing. |
| phone | Inbound Webhook → Data → phone | Phone (if collected). |
| product.title | Inbound Webhook → Data → product → title | Product name as set in Whop. Use for conditional routing. |
| product.id | Inbound Webhook → Data → product → id | Unique product ID. More precise than title. |
| plan_id | Inbound Webhook → Data → plan_id | Checkout link / plan ID. Most specific for routing. |
| amount | Inbound Webhook → Data → amount | Total amount paid. |
| membership_id | Inbound Webhook → Data → membership_id | Whop membership ID. |
| payment_method | Inbound Webhook → Data → payment_method | Method used (card, ACH, crypto, etc.). |
| address.* | Inbound Webhook → Data → Billing → address | Billing address (line1, city, state, zip, country). |
Part 3: Conditional logic — route by product or plan
After the contact is created or updated, add Conditional Logic (If/Else) to split the workflow by what the customer purchased. You can apply different tags, grant different access, send different emails, and run different automations per product or plan.
Step 6 — Add a conditional split
- After Create/Update Contact, add a Conditional Logic (If/Else) step.
- For the condition field, click the tag icon → Inbound Webhook Trigger → Data → choose the field you want to route on.
- Set the condition value to exactly match the product or plan name in Whop.
- Add more branches for each product or plan you want to handle separately.
- Label each branch clearly (e.g., “Free Product”, “VIP Member”, “Monthly Plan”) so the workflow is easy to read and maintain.
Choosing what to route on
| Route by | Specificity | Best when |
|---|
| product.title | Medium | You have distinct product names and want a readable workflow. Value must match exactly as in Whop. |
| product.id | High | You want to avoid breaks if product names change. More reliable long-term. |
| plan_id | Highest | You have multiple plans per product (e.g., monthly vs annual) and need different actions per plan. |
| amount | Variable | You want to branch by price instead of product name. |
When routing by product.title, the value in your condition must be an exact match to the product name in Whop — including capitalization and spacing. A single character difference will fail the condition and contacts will go to the default branch.
Step 7 — Example: Free vs VIP routing
Example of a two-branch workflow by product title:
- Branch 1: Condition —
product.title equals Free (exactly as named in Whop). Actions: Add tag free; optionally grant access to a free GHL offer or course.
- Branch 2: Condition —
product.title equals VIP (exactly as named in Whop). Actions: Add tag vip; optionally grant paid GHL offer/course access, send VIP welcome email.
You can add as many branches as you have products. Each branch can have different tags, courses, emails, or sub-workflows.
Part 4: Actions you can take per branch
Once a contact is in a branch, you can use any GHL action. Common ones:
| Action | Use case |
|---|
| Add Contact Tag | Tag by product (e.g., free, vip, monthly) for segmentation and reporting. |
| Grant Offer/Course Access | Give access to a course, membership, or digital product in GHL. |
| Send Email | Send a welcome email, onboarding sequence, or receipt for what they bought. |
| Send SMS | Send a welcome text or next-step message after purchase. |
| Add to Pipeline | Move the contact to a pipeline stage (e.g., Paid Customer, Active Member). |
| Remove Tag | Remove a prospect tag if they were already in your CRM as a lead. |
| Start Drip Campaign | Enroll in a post-purchase nurture or onboarding sequence. |
| Internal Notification | Alert your team by email or SMS when a new purchase comes in. |
Frequently asked questions
I don’t see the Developer tab in Whop. What do I do?
- The Developer tab is only visible to account Owners.
- If you’re an admin or team member, ask your account owner to update your role.
- You can’t create webhooks without Owner access.
Should I use one webhook for all payment events or separate ones?
- Use separate webhooks and separate GHL workflows for each event — one for Payment Succeeded, one for Payment Failed, one for Refund, etc.
- Mixing them in one workflow makes troubleshooting hard and the logic harder to maintain.
Why do I need to test the webhook before mapping fields?
- GHL needs at least one sample payload before it can show the fields for mapping.
- Without a test, the field selector is empty and you can’t reference Whop data in actions or conditions.
My conditional logic isn’t routing contacts correctly. What’s wrong?
- Most often it’s a case or spacing mismatch between your condition value and the product name in Whop.
- The value in GHL must exactly match the product title in Whop.
- Check for extra spaces, different capitalization, or special characters.
What’s the difference between routing by product title vs plan ID?
- Product title is easier to read but can break if you rename the product in Whop.
- Plan ID is stable and better long-term.
- Use plan ID when you have multiple plans per product (e.g., monthly vs annual) and need different handling in GHL.
Can I capture the amount paid and store it in GHL?
- Yes. The amount field is in the payload under Inbound Webhook Trigger → Data → amount.
- You can map it to a custom contact field or use it in workflow conditions.
What happens if the same customer buys again?
- GHL looks up by email first.
- If the contact exists, it updates that record instead of creating a duplicate.
- The workflow still runs, so a repeat purchase will run the workflow again and apply the tags and actions you configured.
Questions?
Contact your Whop account team or visit whop.com.
