I think it would be cleaner as part of the existing node - but have not thought in detail about the implications of that.

Agreed it would be better to have this in the existing output node.

There are lots of features of the Twitter API we don't support today, so it would be good to keep that in mind when adding individual features.

For this, I'd suggest if the received message includes msg.retweet then use its value as the tweet id to retweet.

The app lets you retweet with comment - but that doesn't appear to be part of the /status/retweet/ endpoint. It would make sense if msg.payload is set to some text as well as msg.retweet set for that to be a retweet with comment - its just a matter of figuring out the right API to use for that.

@baruchiro you are most welcome to explore this and propose something along these lines.

OK, about retweet with text, I'm not sure I will take this. Maybe if it will be on my way.

About the existing output node. First, I agree. But the reason I was thinking to implement a new output node is in order to support the simplest flow, input to output:

Today, if you are wiring such flow, it will tweet the input tweet, as text (or any other content) but not like a real retweet supported by Twitter.

With implementing in the existing node, this simple flow will require another node to take the tweetID and put it in the payload.

was this ever updated to support retweets? I tried using msg.retweet with no success