beehiiv and CodeWords: automating newsletter operations
Assembling issues from what you already publish, keeping subscriber segments honest, reporting to sponsors, and the parts of a newsletter that should never send without a person reading them.
Rebecca Pearson11 min read
On this page
A newsletter is a deadline that arrives whether or not you are ready. beehiiv handles the sending, the subscription management, and the monetization. What it does not handle is the hour before the deadline: gathering what you meant to include, checking the links, pulling the numbers your sponsor asked for, and working out why forty people unsubscribed last week.
That hour is what automation is for, and the distinction worth holding is between assembly, which automates well, and editorial judgement, which does not.
What we'll cover
- Where the hour actually goes
- What the beehiiv API reaches
- Connecting it to CodeWords
- Seven automations worth building
- What should never send unread
- Building it so it survives
- Limits worth knowing about
- Frequently asked questions
Where the hour actually goes
Gathering. The links you saved, the posts you published, the thing somebody sent you on Tuesday. Scattered across a notes app, a spreadsheet, and your own sent messages.
Formatting. Turning that pile into consistent sections with consistent styling, every single week, by hand.
Checking. Do the links work, is the date right, did the sponsor's copy actually get in, is the subject line different from last week's.
Reporting. Opens, clicks, and growth pulled out for sponsors or for your own records, usually late and usually by exporting something.
List hygiene. Subscribers who have never opened anything, bounces, and duplicates that quietly damage deliverability while nobody prunes them.
Four of those five are assembly. Only the fifth item in checking — does this read the way I meant — genuinely requires you.
What the beehiiv API reaches
Publications are the top-level object, and most endpoints are scoped to one, which matters if you run several.
Subscriptions can be listed, created, read, and updated, including custom fields and subscription tiers. This is where segmentation data lives.
Posts can be listed and read, with their statistics, and created programmatically. Post creation is what makes automated assembly possible.
Segments can be listed and their members retrieved, which lets an automation act on a segment your team already defined rather than reimplementing the filter.
Automations within beehiiv can be triggered, so an external event can start a native journey.
Webhooks fire on subscription and post events, which is what lets an automation react rather than poll.
The practical shape: you can read what you published and how it performed, manage who receives what, and create posts. Creating a post as a draft rather than sending it is the arrangement most newsletters should use, for reasons the human-review section covers.
Connecting it to CodeWords
CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder, naming beehiiv and wherever your content and subscriber data actually live.
- Authorize the connection when prompted, using an API key scoped to the publication involved.
- Describe the exceptions: a week with nothing to include, a subscriber who cannot be found, a sponsor block that is missing.
- Run it into a draft and read the result before letting it near a schedule.
You describe the outcome; Cody builds it, connects it, and deploys it. When the format changes you describe the change. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Seven automations worth building
Draft assembly. Collect what you published or saved this week from wherever it lives, format it into your sections, and create the post as a draft. This is the single highest-value automation for a newsletter and it deliberately stops short of sending.
Link checking. Before a scheduled send, verify every link in the draft resolves. A broken link in a newsletter is visible to everyone at once and cannot be recalled.
Sponsor reporting. After each send, pull the statistics for that issue, including clicks on the sponsor's links specifically, into a sheet or a formatted summary. This turns an awkward monthly request into a record that already exists.
Segment maintenance. Recalculate the derived segments — engaged, lapsing, paying, churned — on a schedule, so they reflect current behaviour rather than whatever was true when someone set them up.
Cross-platform subscriber sync. Keep beehiiv in step with wherever else you hold people: a course platform, a community, a payments system. Reconcile and report differences rather than silently resolving them.
Growth reporting. Weekly subscriber change by source, with net growth after unsubscribes. The gross figure flatters; the net figure is the one that tells you whether the newsletter is working.
Churn signal detection. Unsubscribes clustered around a particular issue or topic, surfaced rather than lost in a total. A spike after one send is information about that send.
What should never send unread
The issue itself. Assembly automates well; the final read catches the broken date, the paragraph that says something you did not intend, and the joke that lands differently in print. Generate the draft and read it.
Anything naming a person or a company. Automated assembly can pull the wrong name into the right slot, and the cost of that is entirely borne by your relationship with whoever was named.
Sponsor copy. Contractual obligations about placement and wording are not things to discover an automation got subtly wrong after the send.
Anything time-sensitive that might have changed. An event that was cancelled on Thursday is still in your automated draft on Friday unless something checks.
The general principle: automate until the point where being wrong costs more than the time saved, and put the read there. For a newsletter that point is just before sending, every time.
Building it so it survives
Make it safe to run twice. A draft-creating automation that runs twice produces two drafts, which is untidy but harmless. One that sends produces two sends, which is not. Guard the sending step specifically.
Handle the empty week. A newsletter automation with nothing to assemble should say so rather than produce an empty draft that somebody schedules by habit.
Report the outcome. A message confirming the draft exists, with a link and a count of items included, is what turns this from a thing you hope ran into a thing you know ran.
Keep the template readable. The formatting logic will need changing, probably by you, probably in a hurry. Describing it in plain language rather than burying it in code is what makes that a two-minute job.
Version the sponsor obligations separately. What you owe each sponsor is contractual and should not live only inside an automation nobody else can read.
Limits worth knowing about
Rate limits apply, so bulk subscriber operations need pacing rather than a tight loop.
Post creation has structural requirements around content blocks, so an automation generating posts must produce the shape the API expects rather than arbitrary HTML.
Statistics settle over time. Opens and clicks continue arriving for days after a send, so a report generated an hour after sending will differ from the same report a week later. Say which you are reporting.
Subscription status is the boundary that matters. An automation adding subscribers from another system must check consent rather than assuming a customer record permits email.
Publication scope. API keys are scoped, so a multi-publication setup needs that handled explicitly rather than assumed.
Frequently asked questions
Can I have the newsletter write itself?
The assembly, yes: gathering, formatting, and creating the draft. Whether it sends without you reading it is a choice rather than a capability question, and the newsletters people actually subscribe to are the ones where someone read the draft. Automate the hour of gathering and keep the ten minutes of reading.
How do I keep segments accurate?
Recalculate derived segments on a schedule rather than applying them once. Engagement-based segments decay quietly: somebody tagged "engaged" three months ago may not have opened since, and an automation that only ever adds and never removes produces segments that overlap and mislead.
Can I sync subscribers from another platform?
Yes, and consent is the thing to get right rather than the mechanics. Sync the subscription status and the date it was given, not just the address, and treat an unsubscribe anywhere as an unsubscribe everywhere.
What is the most useful thing to automate first?
Draft assembly, because it removes the largest recurring block of time and its output is something you inspect before it goes anywhere. It is also the one where a mistake costs nothing, since you are reading the result.
How do I report to sponsors without exporting things by hand?
Pull the statistics for the relevant issues after each send into a sheet or a formatted message, including clicks on the sponsor's own links. Doing it on send rather than on request means the answer exists before anyone asks, which is a better position to negotiate a renewal from.
Will automated assembly make the newsletter sound generic?
Only if you let it write. Assembly places your own words and your own selections into a consistent structure, which is the part readers do not notice. The voice comes from what you chose to include and what you wrote about it, and neither of those should be automated.
How do I catch a bad send before it goes out?
Check links, verify the sponsor block is present, confirm the subject line differs from recent issues, and read the draft. The first three automate well and the fourth does not, which is the whole argument for generating drafts rather than sends.
How do I handle a week when there is nothing to include?
Have the automation say so rather than produce an empty draft. An empty draft that gets scheduled by habit is a worse outcome than no draft, and the automation is the only thing in a position to notice.
Can I test without sending to anyone?
Create drafts and read them, which is the arrangement you want permanently rather than only during testing. For anything that does send, use a small segment containing addresses you control before pointing it at the list.
What should the growth report actually show?
Net change by source, not gross subscribers. Gross growth flatters and hides an unsubscribe problem for months. Net by source tells you which channel is bringing people who stay, which is the only version of the number worth acting on.
How do I stop the automation from breaking when I change the format?
Describe the format rather than encoding it, and keep the description somewhere you can read. A layout expressed in plain language is a two-minute change; one buried in template code is an afternoon and a deployment.
What to build first
Start with draft assembly. It removes the largest recurring block of time, the output is something you read before it goes anywhere, and a mistake costs nothing because you are the one checking it.
Two things make the difference between a first automation that sticks and one that gets abandoned. Run it alongside whatever happens now for a cycle or two and compare the outputs, since the differences are nearly always genuine discoveries rather than bugs. And have it report that it ran even when it found nothing, because an automation whose only output is silence is one nobody can distinguish from a broken one.
Can the automation pick what goes in, as well as assemble it?
It can rank and suggest, and the selection is the part worth keeping. What you choose to include and what you say about it is the reason people subscribed, and a newsletter whose contents were chosen by relevance score reads like one. Let it gather and order; you decide what makes the issue.