Been meaning to write this up for a while since a couple people in another thread asked how I handle story reply automation without it turning into a mess. This is the actual setup I’m running right now, not a theoretical “here’s how it should work” post.
Quick context on why this needed its own writeup: story replies are their own beast on Instagram. Meta only opened up the story reply event on the Instagram side, Facebook Pages don’t have anything comparable, so if you’ve been trying to reuse your comment-to-DM scenario for this, that’s probably why it’s been fighting you.
The setup
Instagram Story Reply → InstantDM → Make.com Webhook → Filter → HTTP module back to InstantDM’s send endpoint → Google Sheets log
I’m using InstantDM as the layer between Instagram and Make because it’s already sitting on Meta’s official Graph API and handles the OAuth side, so I don’t have to deal with app review or refreshing tokens every 60 days. That part was genuinely the reason I stopped trying to do this raw against Meta’s API a while back.
Step 1: Wire up the webhook
In InstantDM, go to Settings → Integrations → Webhook Configuration. In Make, drop a Webhooks custom webhook module into a new scenario, copy the generated URL, and paste it in as your endpoint. Every inbound DM (which is what story replies technically are, from Instagram’s side) will start hitting that URL.
While you’re in there, grab your API key from Settings → Integrations → API Keys. You’ll need it in the header of every call you make back to InstantDM.
Step 2: Filter for story replies specifically
This is the part that trips people up. The webhook you’re listening to is dm_received, which fires for any inbound message, not just story replies. Someone just DMing you cold will land in the same payload shape. To isolate story replies, you’re checking for the reply context inside the message object, since Instagram tags story replies with a reference back to the story they came from.
Add a filter on your router before anything else runs, checking that the message payload actually includes that story reference. If it’s missing, route it somewhere else, or just let it fall through to nothing.
Step 3: Send the reply
Add an HTTP “Make a Request” module:
Method: POST
URL: https://api.instantdm.com/api-webhook
Headers:
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
Body:
{
"action": "send_message",
"type": "dm",
"recipient_id": "{{sender_id}}",
"message": {
"text": "Hey! Thanks for reacting to my story 👋 here's that link: [your link]"
}
}
Same endpoint InstantDM uses for everything else, comment replies, flow messages, all of it. One header, one action name, and you’re sending.
Step 4: Log it somewhere useful
I run a second branch off the router into Google Sheets, Add a Row, mapping the sender ID, username if you’re pulling it, timestamp, and whatever tag you want for that story (I use the story ID so I can tell which story is actually driving replies over time). Doesn’t affect the reply speed since it runs in parallel.
A couple of things that’ll save you a headache:
The 24 hour messaging window still applies here same as any other DM. If someone replies to a story and you don’t get a message back to them within that window, Meta blocks it, no way around that through the API.
InstantDM’s webhooks are fire and forget, no retries. If your Make scenario is down or times out, that event is just gone. I learned this the annoying way after a scenario got paused for an unrelated reason and I lost about four hours of story replies before I noticed.
If you set a webhook secret, verify the X-Webhook-Signature header before trusting the payload. Takes two minutes to add and saves you from processing spoofed requests.
Also worth knowing, webhook delivery only happens on paid InstantDM plans, the free tier is fine for testing the flow manually but won’t actually push events to Make until you’re on something eligible.
Honestly the built in story reply trigger inside InstantDM’s own flow builder handles the simple “someone replies, they get a DM” case without touching Make at all. Where this webhook route earns its keep is once you want that reply logged somewhere, pushed into a CRM, or chained into something else you’re already running in Make.
Happy to answer questions if anyone’s trying to adapt this for a multi step flow or wants to route story replies differently based on which story triggered it.