Kit.com Integration

This is a member-only chapter. Log in with your Signal Over Noise membership email to continue.

Module 4: Kit.com Integration

Kit.com (formerly ConvertKit) is where Signal Over Noise and Second Brain Chronicles actually send. The email delivery, the subscriber management, the tagging, the sequences — all of it lives there.

For a long time I managed all of it through the web dashboard: click to create a broadcast, paste in the content, set the subject line, click again to schedule. It works. It’s also slow, breaks your flow when you’re in a terminal-based pipeline, and makes it hard to automate the distribution end of the process.

The Kit CLI changed that. Every operation the web dashboard supports is available from the terminal, and the output is JSON — which means it pipes cleanly into other tools and Claude Code agents.

What the Kit CLI Can Do

The CLI covers the full Kit.com API surface. The commands you’ll use most often in a newsletter pipeline:

Account and subscriber management:

kit account                              # Account info and subscriber count
kit subscribers list                     # All subscribers (paginated)
kit subscribers list --status active     # Active subscribers only
kit subscribers get <subscriber-id>      # Individual subscriber details

Tags:

kit tags list                            # All tags with IDs
kit tags subscribers <tag-id>            # Subscribers with a specific tag

Tags are how Kit.com segments your list. “newsletter-auto-buyer” is a tag. “son-paid” is a tag. When someone purchases a product, they get tagged; your sequences and broadcasts target tags rather than the whole list. Understanding your tag structure is foundational to any automation.

Broadcasts:

kit broadcasts list                      # All broadcasts (drafts and sent)
kit broadcasts get <broadcast-id>        # Details for a specific broadcast

The CLI currently supports reading broadcast data. Creating and scheduling broadcasts is handled through the Kit.com API directly, which the pipeline calls via a Claude Code agent with the API credentials configured.

Sequences:

kit sequences list                       # All sequences with IDs

Sequences are automated email series — onboarding flows, product drip campaigns, re-engagement series. They run on Kit.com’s scheduler without you touching anything after setup. The CLI lets you audit what sequences exist and how they’re configured without navigating the web dashboard.

Forms:

kit forms list                           # All opt-in forms with subscriber counts

Setting Up the Kit CLI

The CLI is installed globally:

npm install -g @convertkit/cli

After installation, authenticate with your Kit.com API key:

kit auth

This prompts for your API key and secret, which you’ll find in Kit.com’s developer settings. Once authenticated, the credentials are stored locally and all subsequent commands use them automatically.

Test that it’s working:

kit account

If you see your account information, the CLI is connected.

Connecting to Claude Code

The Kit CLI becomes genuinely powerful when Claude Code agents can call it. The setup is two parts: put the credentials in environment variables, and give your agents permission to run the CLI commands.

In ~/.zshrc (or your shell’s config):

export CONVERTKIT_API_KEY="your-key"
export CONVERTKIT_API_SECRET="your-secret"

The kit CLI reads these automatically. Claude Code agents that have Bash tool access can then run kit commands as part of their workflow.

In your Claude Code settings, you’ll need to allow the kit command in trusted commands or run in a context where the agent has shell access. The agent can then do things like:

Check subscriber growth after sending an issue
Verify that a tag exists before creating a segment
Pull broadcast stats for a performance summary
List current sequences to avoid creating duplicates

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.

Tag-Based Segmentation

The product catalogue on the Signal Over Noise members platform uses tags for access control. When someone buys a product, Kit.com tags their subscriber record, the auth system checks for that tag, and they get access.

This creates a useful pattern for newsletter automation: different subscriber segments can receive different content. Members who have the co-op-system-buyer tag might get an additional section in certain issues with tips that assume they’ve already read that product. Everyone else gets the standard issue.

The Kit CLI makes it easy to check tag membership and build the logic:

# How many active subscribers?
kit subscribers list --status active | jq '.total_subscribers'

# Who has the newsletter-auto-buyer tag?
kit tags list | jq '.[] | select(.name == "newsletter-auto-buyer") | .id'
# → then
kit tags subscribers <tag-id> | jq '.[] | .email_address'

This is where you start building audience intelligence into the pipeline rather than treating all subscribers identically.

What the Dashboard Is Still Good For

The CLI covers everything you need for pipeline automation. It’s not a replacement for the dashboard for everything.

The Kit.com visual sequence builder is genuinely good. Setting up a new onboarding sequence from scratch is faster in the UI than constructing it via API calls. Same with the broadcast email editor when you want to check how something renders before scheduling.

The rule I use: if it’s a recurring automated action (schedule a broadcast, check subscriber growth, verify a tag), it goes through the CLI. If it’s a one-off setup task (build a new sequence, redesign an email template), the dashboard is faster.

Sequences for Product Buyers

One automation that runs entirely without me: when someone buys a product, Kit.com fires a sequence that delivers the access link, onboards them to the members platform, and sends three to five follow-up emails over the next two weeks introducing them to related products.

This runs on Kit.com’s scheduler. I built the sequences once in the web UI, and they’ve sent hundreds of times since without me touching them. The Kit CLI is how I audit them — checking delivery stats, verifying that the right tags are triggering the right sequences, monitoring for failures.

kit sequences list | jq '.[] | {id: .id, name: .name, subscriber_count: .total_subscribers}'

That command gives me a quick view of which sequences are active and how many people are in each one. Useful for spotting if a sequence stopped firing after a product was removed or a tag was renamed.

Module 5 puts it all together: the full workflow from topic to sent issue, what to automate and what to keep human, and the principle that keeps the automation from making your newsletter worse.