Skip to main content
Solved

Is the post ID available as a variable in a comment-triggered flow?

  • August 14, 2026
  • 4 comments
  • 57 views

Hi everyone,

I am building an Instagram comment automation: one automation, triggered on any
post or reel, with a list of keywords. When someone comments, I want the flow to
call my own server with "Make an external request" and get back a link that
depends on which reel was commented on, because each reel offers a different
resource.

Two questions:

1. Is the ID of the post or reel that triggered the flow available as a variable
   that I can include in the external request?

2. Is the text of the comment available the same way?

Thanks a lot.

Best answer by Anthony 56860

Thanks Fabio, and sorry for the slow reply. Your answer settles it, and I confirmed it independently on my side: ManyChat's system fields carry no post ID, no comment text and no matched keyword, and the API can read flows but not create them. So there is genuinely no way around one automation per post.

Your three-block pattern is exactly what I ended up building: trigger on the post, an Action block that writes the resource key into a Custom User Field, then Start Automation into one central flow that makes the external request. The per-post work stays around a minute and the logic lives in a single place.

One caveat worth adding for whoever lands here later: the keyword has to be unique per resource and never reused, or two posts will collide on the same word. Thanks again for the quick and accurate answer.

4 replies

Fabio Gaulke
Forum|alt.badge.img+3
  • Community Moderator
  • August 14, 2026

Hi, ​@Anthony 56860!

 

Unfortunately, Manychat does not provide the post ID or the comment text as native system variables to be used in standard flows...

 

The only way to achieve this setup is to create a specific comment-triggered automation for each post or reel you want to run this on. In each of these individual triggers, you can set a Custom User Field with the specific information about that origin post, which you can then pass along in your external request. But that only covers the origin of the trigger, not the text of the comment.

 

And if the flow itself is long or complex, a good practice to simplify maintenance is to keep the trigger automation very short:

  1. Set up the trigger for the specific post.

  2. Add an Action block to set the Custom User Field with that post's information.

  3. Use a "Start Automation" step to direct the flow to your main, central automation where the rest of the logic and external request take place.

It will look something like this:

 

This way, if you need to make changes to your main server request or logic in the future, you only have to edit one single flow instead of updating every post automation.

 

Hope this helps!


  • Author
  • Up-and-comer
  • Answer
  • August 19, 2026

Thanks Fabio, and sorry for the slow reply. Your answer settles it, and I confirmed it independently on my side: ManyChat's system fields carry no post ID, no comment text and no matched keyword, and the API can read flows but not create them. So there is genuinely no way around one automation per post.

Your three-block pattern is exactly what I ended up building: trigger on the post, an Action block that writes the resource key into a Custom User Field, then Start Automation into one central flow that makes the external request. The per-post work stays around a minute and the logic lives in a single place.

One caveat worth adding for whoever lands here later: the keyword has to be unique per resource and never reused, or two posts will collide on the same word. Thanks again for the quick and accurate answer.


cata_rendon
Forum|alt.badge.img+5
  • Community Moderator
  • August 20, 2026

Hi ​@Anthony 56860 no it is not. 🙄 You can follow ​@Fabio Gaulke advice for a workaround.


  • Author
  • Up-and-comer
  • August 20, 2026

Thanks Catalina, that's exactly the confirmation I was after. Having it from a moderator settles it: the limitation is by design, not something I had misconfigured on my side.

 

Marking this closed. For anyone landing here later, the short version is that the post ID is not exposed as a variable in a comment-triggered flow, and Fabio's Custom User Field workaround is the way to handle it, with one unique keyword per post and never reused.