Broadcast Scheduling in the Pipeline
This is a member-only chapter. Log in with your Signal Over Noise membership email to continue.
Log in to readModule 4 · Section 5 of 8
Broadcast Scheduling in the Pipeline
The end of the content pipeline is queueing the issue in Kit.com. This is what that stage looks like in practice.
After the draft-reviewer signs off on the issue, I’m left with a polished markdown file. The pipeline converts it to HTML (Kit.com accepts HTML in broadcast creation), sets the subject line and preview text, and calls the Kit.com API to create a draft broadcast.
The API call to create a broadcast looks like this:
curl -X POST "https://api.convertkit.com/v3/broadcasts" \
-H "Content-Type: application/json" \
-d '{
"api_secret": "'$CONVERTKIT_API_SECRET'",
"subject": "Your subject line here",
"content": "<p>HTML content here</p>",
"description": "SoN Issue 032 - Topic Name",
"email_layout_template": null,
"published_at": "2026-03-19T09:00:00Z"
}'
The broadcast is created as a draft with a scheduled send time. I review it once in the Kit.com dashboard before it goes out — checking that the formatting survived the HTML conversion and the subject line is right. Then I either let it send at the scheduled time or push the button manually if I want to be there when it goes.
The review step before sending is deliberate. Fully unattended sends are possible but I don’t use them. One final human check before something goes to the full list is the right call.