The assumption
When I saw the Buttondown section in my Scribbles blog settings, I assumed Scribbles would turn my posts into a newsletter on its own. It doesn’t. The integration stores a Buttondown username, a heading and a description, and that’s it: a theme can show a subscribe form wired to my Buttondown list. People can subscribe, and then nothing is ever sent.
I only connected Buttondown to Blips yesterday, and the form didn’t appear on the blog at all until I updated my custom theme to show it. So before anyone could subscribe and wait for an email that would never come, I built the missing piece: a monthly digest of every post, generated by an n8n workflow from the Scribbles API and created in Buttondown through its API.
Buttondown’s own answer to this is RSS-to-email, and I ruled it out for two reasons.
- It’s a paid add-on. My newsletter is on Buttondown’s free plan, which includes the API but not RSS-to-email.
- The feed is too short. The Scribbles feed only carries the latest 15 posts. In a busy month I post more than that (September had 17), so a monthly digest built from the feed would quietly drop the oldest ones.
The Scribbles JSON API doesn’t have that limit. It takes a date range, pages through results, and returns each post’s full content. That made it the right source.
The workflow
The workflow has six nodes and runs on the 1st of each month at 8:00, Montreal time. It covers the previous calendar month.
- Two triggers. A Schedule Trigger fires monthly on the 1st. A Manual Trigger lets me run the same path on demand for testing.
- Config (Set node). Every setting lives here: the mode (
draft or send), the blog ID, name and URL, the subject prefix, an optional intro note, the maximum text length per post, and whether to show categories. It also computes the month with Luxon: the previous month in the America/Toronto time zone. The date range sent to the API is padded by a day on each side, so posts near midnight UTC aren’t lost.
- Fetch (HTTP Request).
GET /api/v1/posts on the Scribbles API with blog_id, type=posts, from_date, to_date, include_content=true and limit=100, authenticated with a bearer token. n8n’s built-in pagination increments page until pagination.page reaches pagination.pages. The node retries up to three times.
- Build Digest (Code node). Merges the pages, drops duplicates, and keeps only published posts that aren’t hidden or excluded from RSS. It then applies the exact month boundaries in Toronto time, sorts by date and builds the email body. If the month is empty, it returns nothing and the workflow stops there, so no empty email is ever created.
- Create email (HTTP Request).
POST /v1/emails on the Buttondown API with the subject, the body and a status: draft while testing, about_to_send once it’s live.
Failures go to my shared error workflow, like every other workflow on my n8n instance. A digest that silently doesn’t go out is worse than one that fails loudly.
Designing the email
The first draft was too airy, and the second one fits the same 17 posts in about a third of the scrolling.
Version one gave each post a heading, a full-width photo, a 300-character excerpt and a “Read the blip” link, with a rule between entries. On a phone, a month of blips became a long scroll with little on each screen.
Version two is built for density:
- Full text. Blips are short, so each one goes in whole, with its own links kept: the trail links, the article I’m pointing to, the YouTube video. Only posts over 700 characters get trimmed, with a “Read more” link.
- Small photos. When a post has a photo, it becomes a 96-pixel thumbnail on the right of the text.
- Tighter entries. The title is the link, followed by the date in grey. No separators, no extra links.
- Short link labels. Long URLs show as
glass.photo/…/iphone-18-pro-max instead of the full address.
- No category line. My titles already carry the category ("📡✨" for blips, “→ Links 🔗” for links), so repeating it was noise. A setting brings it back.
The body is HTML, not Markdown. Buttondown accepts both, but Markdown can’t size an image or place a thumbnail beside text, and that’s what makes the layout compact. The thumbnail rows use a simple table, which is still the most reliable way to lay out two columns across email clients.
Snags along the way
The Scribbles side worked on the first run; Buttondown authentication took several tries.
- Token, not Bearer. Buttondown expects
Authorization: Token <key>. My first credential was n8n’s Bearer Auth type, which sends Bearer <key>, and Buttondown answered 401 with a helpful message saying exactly which header it wanted.
- Header Auth is the fix, but its fields are literal. In n8n’s Header Auth credential, “Name” is the HTTP header name, not a label for the credential. It must be
Authorization. “Value” must be Token, one space, then the key. A stray space or a re-pasted wrong key gives the same 401, so if it keeps failing, copy the key again from Buttondown’s API settings.
- Embed shortcodes in the text. A post’s plain-text version still contains Scribbles embed codes like
{{yt:https://youtu.be/…}}. The builder now turns those into plain links, and YouTube embeds in the HTML become a “Watch on YouTube” link.
The form lives in my custom Scribbles theme and needs no JavaScript. It’s a Liquid snippet that reads the Buttondown username from the blog settings, so changing it in Scribbles updates the form everywhere. If the username is blank, the form doesn’t render.
The form posts the email address straight to Buttondown’s embed endpoint, https://buttondown.com/api/emails/embed-subscribe/<username>, with embed=1, and opens the confirmation in a new tab. It appears in two places: the left sidebar, and under each individual post, where a reader who just finished a blip is most likely to want more. The heading and description come from the same Scribbles settings, with a default heading when they’re empty.
Where it stands
The workflow is built and tested in draft mode, and the first real issue goes out November 1, covering October.
So far every run has created a draft in Buttondown, which let me review September’s digest as a real email before anything reached subscribers. The remaining steps are small: confirm a fresh signup through the form, flip mode from draft to send in the Config node, and activate the schedule. The send path hasn’t run yet, so the first live issue is also its first real test.
What I like about this setup is that nothing is locked in. If Scribbles adds a native newsletter one day, or I move the list elsewhere, the workflow is five steps I can change or retire in an afternoon.
