Broadcast Scheduling in the Pipeline

Module 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.