While you may have read that I love Mastodon, what I did not say clearly enough the first time around is that discoverability on an open platform is never going to feel exactly like the algorithm machines we left behind. That is a good thing. It also means if we want to surface what is hot on our own instance, we sometimes have to build a little bit of glue ourselves.
That is where Node-RED still fits nicely. We can read the current trending tags from Mastodon, pull out the top result, and publish a short automated toot that points followers toward what is active right now. The basic idea from 2020 still works. What changed is the endpoint name, the auth wording, and a few practical details that are worth tightening up so the bot stays useful instead of turning into one more loud machine on the timeline.
Solution – Call the Mastodon API with Node-RED
The flow is still simple:
- Read trending tags from your instance with an HTTP Request node.
- Use Change and Function nodes to isolate the top tag and build a short status message.
- Publish the message with either the Mastodon contrib node or a plain HTTP POST to Mastodon.
The nice part is that the read step is public on most public instances and the write step is not. So we can test the trends call first without a token, make sure the flow behaves, and only then add the credentials needed to post.
Calling the API
Start with an Inject node and an HTTP Request node. Point the request at your own instance and call the current trends endpoint:
GET https://your-instance.example/api/v1/trends/tagsIf you are following my older guide and see /api/v1/trends, treat that as legacy syntax. Mastodon now documents /api/v1/trends/tags as the current path and keeps the older form around only as a deprecated alias.
Set the HTTP Request node to return a parsed JSON object. Then wire in a Debug node and inspect the full message object before moving fields around. If your instance has trends disabled, lightly populated, or just quiet at the moment, you may get an empty array back, so it is worth checking the shape early instead of pretending every server behaves like mastodon.social on a busy day.
If you also want to post back to Mastodon later in the flow, create an application on your instance and generate a user token with write access to statuses. Keep that token for the final publishing step only. There is no need to muddy the read call and the write call together.
Copying the Top Tag
When the trends endpoint returns data, the top item will usually be the first object in the array. In the original version of this post I moved msg.payload[0].name directly into msg.payload. That still works, but it is a little clearer to move it into a named property such as msg.topTag.
msg.payload[0].name -> msg.topTagThat makes the rest of the flow easier to read and easier to debug. It also gives you an obvious place to stop the flow if there is no top tag available, which is much better than firing off a broken toot because the server had nothing interesting to report.
Crafting our Toot
Once we have isolated the top tag, a Function node can turn it into a short toot. Keep the message simple and avoid posting too often. People will tolerate a useful daily automation a lot longer than they will tolerate a bot that acts like it discovered caffeine.
const topTag = msg.topTag;
if (!topTag) {
return null;
}
msg.payload = `Today's top trending tag is #${topTag}. What are you seeing on this instance? #trending #automated`;
return msg;This version uses a named variable, stops cleanly if there is no result, and keeps the outgoing message short enough that you can tune it for your own instance without turning it into marketing sludge.
Moving our Payload to our Toot
If you are using node-red-contrib-mastodon, the outgoing sendMessage node expects the text in msg.payload.text. That means you need one more Change node before publishing:
msg.payload -> msg.payload.textI still like the convenience of that contrib node, but it is worth saying out loud now that you can also skip it and post directly to Mastodon with another HTTP Request node if you want to stay closer to the raw API.
POST https://your-instance.example/api/v1/statuses
Authorization: Bearer <user_token>In that direct HTTP version, the important value is the status field you send to Mastodon.
Rate Limiting and Scheduling
This is the part that deserved more care than I gave it the first time. If you want a daily bot, make it daily in both the prose and the flow. One of the easier ways to make a small automation feel sloppy is to say “daily” while the exported flow is quietly doing something else.
An Inject node can trigger the flow on a schedule by using an interval or a cron expression. Once a day is enough for this idea. We do not need a noisy repeat loop, and we do not need to mix a startup hack with a long repeat interval unless there is a specific reason for it.
It is also smart to keep a Delay node or other rate control in place so you do not accidentally post more than once during testing. If you want to be extra careful, store the last posted tag and skip the write step when the top trend has not changed. There is no prize for being the loudest robot on the instance.
Sending our Toot
When you are ready to publish, this is the point where authentication matters. Mastodon’s status-posting endpoint requires a user token with write:statuses. In other words: read trends publicly, write statuses with a bearer token.
If you use the sendMessage node, make sure the instance URL and token are correct for your own server. If you use a plain HTTP Request node instead, send the bearer token in the Authorization header and post the status text to /api/v1/statuses.
Either way, keep the automation polite. Different instances have different moderation norms, and a status that is technically valid can still be annoying if it fires too often or adds no real value. That part has not changed since 2020.
Putting it Together – API to Toot
I still like the idea of giving readers something copyable, but I do not want to paste the old flow back in here unchanged when the endpoint and schedule details have moved. If you build the flow today, make sure it reflects the following:
GET /api/v1/trends/tags- a clean daily Inject schedule
- a null guard when no trend is returned
- explicit write auth for the final post
- an optional fallback to direct HTTP posting if the contrib node does not fit your setup
That keeps the article true to its original purpose without pretending nothing has changed since 2020. The workflow is still simple, still useful, and still a good excuse to glue Mastodon and Node-RED together for a lightweight automation project.
If you want more Mastodon context first, read Not Lame: Mastodon & The Fediverse. If you want a related automation pattern, see Using MotionEye and Node-RED to Send Images and Video to Mastodon.