A few people asked me about this after my last post, so let me actually break it down properly. The short version: InstantDM handles the messy Instagram side (keyword detection, private replies, all that), and Make.com is where the lead actually becomes useful — logged, tagged, and pushed wherever I need it to go. Here’s how I connect the two.
Quick context on why I even split it this way. I used to try building the entire thing inside Make, from catching the comment all the way to storing the lead. It worked, technically, but Instagram’s API quirks (rate limits, the messaging window, comment vs DM triggers) meant I was constantly fighting the platform instead of focusing on what happens after someone raises their hand. Letting InstantDM own that first layer and handing off to Make once there’s an actual lead made everything way less fragile.
Here’s the setup.
Step 1: Connect InstantDM to a webhook in Make
In Make, create a new scenario and start with a “Custom Webhook” module. This gives you a URL. Drop that URL into InstantDM’s integration settings where it asks for a webhook or export destination. Once that’s connected, every qualifying lead InstantDM captures — someone who commented a keyword, opted into a DM flow, whatever trigger you set up — gets sent straight to Make the second it happens.
Step 2: Run one test lead through it
Before building anything else, trigger a test event from InstantDM (usually there’s a “send test payload” option, or you can just comment the keyword yourself). Go check your Make scenario’s execution history and look at what data actually came through — username, the keyword they used, timestamp, any custom fields you set up. You need to see the real structure before you can build around it. I skipped this step once and built half a scenario around a field name that didn’t actually exist in the payload.
Step 3: Add a filter for lead quality (optional but worth it)
Not every “lead” is actually a lead. If you’re capturing multiple keywords for different offers, add a filter here to route them differently — a “PRICING” comment probably deserves a different next step than a “GUIDE” comment. I use a router module right after the webhook so each keyword type follows its own path instead of dumping everyone into the same pile.
Step 4: Push it into your CRM or spreadsheet
This is the actual point of the whole thing. Add a Google Sheets, Airtable, or CRM module (I use Sheets for simplicity, but plug in whatever you’re already using) and map the fields from the webhook — username, keyword, timestamp, source post if you’re tracking that. This is what turns a DM interaction into something your future self can actually act on.
Step 5: Add a notification so you actually see it
I added a simple Slack message module that pings me whenever a new lead comes through. Sounds small, but before I added this, leads would just sit in a spreadsheet I forgot to check for days. Now I know within seconds when someone’s engaged, which matters a lot if you’re trying to follow up while the interest is still warm.
Step 6: Optional — trigger a follow-up sequence
If I want more than just a logged lead, I’ll add a delay and a follow-up email or DM reminder a day or two later. This part lives entirely in Make since InstantDM’s job was really just getting the person into the system in the first place.
A couple of things worth knowing before you set this up:
Test your webhook with a real (or realistic) payload before assuming it’s working. Webhooks fail silently more often than people expect, and if InstantDM’s payload structure ever changes, your Make scenario needs to be checked, not just assumed fine.
Also, don’t overbuild this on day one. My first version had five different routes for five different keywords before I even had ten leads coming through. Start with one path, get it solid, then branch out once you actually have volume to justify the complexity.
Splitting it this way — InstantDM catching the Instagram-side chaos, Make handling everything downstream — has honestly made this the least annoying part of my whole automation stack, which says a lot considering how much time I used to spend debugging comment triggers.
Let me know if anyone wants me to share the actual scenario blueprint, happy to drop it below.