I’m exploring options for creating a contact via a webhook. We collect leads via Microsoft’s Partner Center, which allows us to send those leads to a webhook. Right now we are solving this via Make, which then creates a contact in HS.
However, we now upgraded to the Enterprise Platform, giving us full access to all features and I’d like to consolidate as many workflows as possible within HS. So now I’m looking into ways that we can have a webhook in HS, which triggers the creation of a new contact.
But I’m now a bit stuck there. Via the workflows, webhooks can only be used for existing contacts, since those will then be enrolled in teh workflow. But in this case, we get infos on leads that are not yet in the system - therefore, these contacts should then be created.
I have no way of specifying the webhook request coming from the platform, i.e. I can’t use the forms API or similar.
Hi @FButteron,
Thank you for posting to the Community!
I’d like to tag in some of our Top Contributors to see if they have any tips on this -- Hi @derekcavaliero@Danielle_J and @TDwebdev Do any of you all have any ideas on this one?
Happy New Year!
Cassie, Community Manager
I just wanted to add these context around creating contacts from external webhooks in HubSpot Enterprise. The key point is that HubSpot workflows only trigger on existing records, so there’s not a ‘fully native way’ to have a webhook both create a contact and immediately trigger a workflow.
That’s why most solutions involve a small ingestion step, that allows whether Make.com, a lightweight serverless function, or another minimal middleware that aims to create the contact first. Once the contact exists, workflows can then handle all subsequent actions reliably. This pattern is standard at Enterprise scale and keeps everything within HubSpot-supported boundaries.
If you’d like, I can outline a HubSpot-native-friendly pattern for handling external leads efficiently while keeping workflows safe and automated. It’s a way to reduce middleware overhead without breaking HubSpot’s reactive model.
HubSpot workflows are reactive—they trigger on existing records (property changes, list membership, form submissions). HubSpot has no native webhook receiver endpoint that accepts external payloads and creates new contacts from scratch.
Keep Make.com minimal - Use it only for webhook ingestion → contact creation, then let HubSpot workflows handle everything else
Build custom webhook endpoint - Serverless function (AWS Lambda, Cloudflare Worker) that receives webhook and POSTs to HubSpot API
Use HubSpot Private App + middleware - Create private app for API access, use any webhook receiver (n8n, Pipedream) to transform payload and create contact
Honestly, I’d stick with Make.com for now. You’ll spend more time and money building a custom solution than just keeping one simple scenario running. It’s literally designed for this—receiving webhooks and making API calls.
I’ve built this exact setup if you want to discuss implementation details.
Since you’re on Enterprise, here’s an alternative to keeping Make.com — you can use a serverless proxy with HubSpot’s Private App:
**Solution: Lightweight Webhook Receiver**
1. Deploy a simple serverless function (AWS Lambda, Cloudflare Worker, or Vercel Edge Function)
2. Create a HubSpot Private App with Contacts write permission
3. Configure Microsoft Partner Center to POST to your function’s URL
4. Function receives webhook → transforms payload → creates contact via HubSpot API
**Why This vs. Make.com:**
- Lower cost ($0-5/month vs Make.com subscription)
- Faster response time (< 100ms)
- Full control over transformation logic
- No external dependency
**Caveat:** You’ll need basic Node.js knowledge for deployment. If your team doesn’t have dev resources, Pradip’s advice to stick with Make.com is solid — it’s reliable and battle-tested for exactly this use case.