Use Make and Substack to Automate Newsletter Distribution

Table of Contents

Setting up the initial Make scenario

I had a tab open in Make for days with the scenario skeleton just sitting there — an empty trigger bubble hanging out on the left, Substack icon floating in the middle with that little red exclamation mark that tells you nothing useful. The plan seemed simple: I wanted a folder where I’d drop updated text files, Make would pick them up, and then Substack would automatically send them as a newsletter. Easy in theory.

The first bump happened immediately. The Substack integration is not native in Make, which means you either hook into it via RSS or Webhooks. I tried RSS first, which meant generating the RSS URL from Substack (you find it linked in your settings under your publication’s feed). But every test pull in Make returned zero items, even though I had three fresh draft posts sitting there. Turned out the RSS only shows published posts, so I had been testing against a blank feed. ¯\\_(ツ)_/¯

So, I scrapped the RSS start and switched to a Webhook trigger. Webhooks in Make can listen for incoming data, so the idea was to send a trigger from my drafting environment whenever I finalized a post file. I set the Webhook, clicked the “Copy address” button, and pasted it into a tiny automation script I keep in VS Code. When testing the webhook, I saw the payload instantly in the Make scenario execution log, which was a relief — at least something fired.

The Substack part, though, wasn’t plug-and-play. Without a native module, you either have to treat it like a generic HTTP request or use the email-to-post feature Substack offers (buried in your settings under Email submissions). If you use email submissions, Make can just send an email to that special address with the post content. That’s what I ended up doing. The HTTP route looked nice but publishing required authentication tokens I didn’t want to deal with right then.

Formatting the content for Substack emails

My first “real” test email to Substack looked horrendous — no line breaks, weird spacing, and the title jammed onto the first line of the body. This is where beginners often hit that wall, because plain text and HTML formatting get treated differently depending on how Make passes it along.

If you send through the Gmail module in Make, you need to switch the body format to HTML in the advanced fields and manually set your breaks with <br> tags. For Substack’s purposes, a minimal HTML body with <h1> for the title and plain paragraphs is enough. So my Make email body template ended up like this:

<h1>{{postTitle}}</h1> <p>{{postBody}}</p>

I had to put double curly braces because Make uses them to insert variables pulled from your Webhook data. The wild part — even after setting it up perfectly — was that the first send went through without the title showing in Substack’s “Post title” field at all. It just used the email subject. Which, okay, I can live with, but it means you have to treat your email subject line like your official Substack title.

This is also where I found it very handy to keep a “scratch” post in Substack just to see how the formatting lands before spamming actual subscribers. You publish to “only me” in the visibility dropdown and it will render exactly as a real send without hitting anyone’s inbox. 🙂

Deciding whether to draft or auto send

When the first working draft auto-published to all subscribers without my permission, I about choked on my coffee. Apparently email-to-post in Substack always treats incoming messages as publish-now unless you send them from an address marked as a contributor but not the owner. That setting is buried — you have to edit the contributor permissions and tick the “Can only draft posts” option.

My compromise was to build two separate scenarios in Make: one that sends to my contributor-only address so it lands as a draft, and another that sends to my main address when I’m ready to auto-send. I trigger the draft one daily so I can keep a live backup of anything I drop in my local folder, and then if it’s ready to go, I just hit the other scenario manually. There’s no graceful toggle for this unfortunately.

If you’re doing repeated sends, also note that Substack doesn’t treat the same title as a duplicate — it will happily send the same post twice if you push it twice. I learned that one the hard way on a Friday when half the replies were just, “Hey, you already sent this.” 😛

Handling Make scenario failures

Make’s failure notifications are weird — you don’t get them in the interface unless you open execution history, but you can set up a separate scenario to catch and forward them somewhere else. I made a little “Monitor” scenario that runs every 10 minutes, checks the last execution status of my newsletter scenario, and if it finds a failure, sends me a Telegram message.

One common failure was Gmail’s daily send limit. If you blow through it, Make just shows a vague red failed label on the Gmail module, but the rest of your run is fine. That means your webhook fired, your data processed, and then… nothing hits Substack. You have to either split your sends across multiple Gmail accounts or upgrade to a sending service like SendGrid configured with SMTP.

Also, if a scenario fails on the HTTP module route, Make saves the exact error payload. Scrolling that tiny dark box in the execution detail pane is annoying, but it’s worth looking because Substack’s spam filter throws plain text messages back with a reason.

Testing with a dummy Substack list

To avoid sending junk to paying subscribers, I created a completely separate publication in Substack just for testing. Free tier works fine for that. This way I can test Make runs without scaring off the real audience. The catch — if you use the email-to-post method — is that you need a unique email submission address for every publication, so remember to swap it in your Make module when you’re staging.

I keep a table like this in Notion so I don’t forget which address goes where:

Without that table, I guarantee I’d send dummy text to my main list again.

Small quirks that kept tripping me

– If you send HTML that’s too minimal, Substack still wraps it in its own style sheet, which can mess up line heights.
– Make occasionally holds queued runs if your account hits the operation limit, but it doesn’t warn you until you check the dashboard.
– The email forwarder method bypasses the Substack editor, so all your paragraph breaks and inline links need to be correct before sending.
– If you pause a scenario in Make, it’s not obvious it’s paused unless you hover the little dot under its name.

When the fallback route never triggered

I built one Make route as a failsafe — if the primary Gmail send failed, it would hit an HTTP module instead to send via an API. During testing, Gmail failed three times in a row… and Make just stopped execution without ever hitting the fallback. There’s a checkbox buried in the router properties called “Ignore errors and continue” that has to be ticked for alternate paths to run after a module fails. Without it, Make just gives up as soon as any branch breaks.

That box solved it instantly, but by then I had already spent an hour rewriting the same post draft locally thinking it was a Substack problem