Blog PostBy Updated

ConvertKit Webhook Integration with Twilio and n8n

Build a ConvertKit webhook integration with n8n and Twilio using signed events, consent checks, deduplication, delivery callbacks, retries, and opt-outs.

ConvertKit Webhook Integration with Twilio and n8n

Kit, formerly ConvertKit, can trigger a Twilio text when a subscriber joins a form, receives a tag, or changes state. I use an automation layer between the two systems so consent checks, retries, delivery updates, and opt-outs do not get buried inside one outbound API call.

This walkthrough uses n8n because it gives you clear control over those steps. The same data model also applies if you later move the workflow into custom code.

Use this page for the step-by-step Kit-to-Twilio integration. If you are choosing how to operate an audience or batch send, compare the ConvertKit SMS and Twilio bulk SMS architectures instead.

How a ConvertKit webhook integration works

There are two different directions that people often call a ConvertKit webhook integration:

  • Kit to n8n: Kit sends an event when a subscriber joins a form, receives a tag, unsubscribes, or completes another supported action. An n8n Webhook node receives the event and decides what should happen next.
  • n8n to Kit: another system starts the workflow, then n8n uses Kit's API or Kit node to add a subscriber, change a tag, or update a field.

A two-way integration uses both directions. It is not one continuous sync. Each direction needs its own trigger, identifier, retry rule, and record of what has already been processed.

Kit's current webhook guidance says webhook deliveries are signed. It also notes that high-volume events can arrive in batches of up to 100 and that failed deliveries may be retried. The n8n receiver should therefore verify the signature, accept both one-event and batched payloads, and deduplicate events before changing data or sending a message.

This walkthrough implements the first direction: a Kit event enters n8n, passes consent and duplicate checks, and creates a Twilio message. If your actual requirement is to push data into Kit, keep the same validation and state controls but replace the Twilio step with the relevant Kit API operation.

What you need

  • A Kit account and API key
  • A Twilio account, approved sender, and Messaging Service
  • An n8n instance with a public HTTPS webhook URL
  • A Kit field or external record that proves SMS consent
  • A test recipient who has agreed to receive the message

If you send application-to-person messages to U.S. numbers from a 10-digit long code, complete Twilio's required A2P 10DLC registration before production sending.

1. Choose a Kit event

Kit's v4 API supports webhook events for form subscriptions, tag changes, subscriber activation, unsubscribes, purchases, and other subscriber activity. The official Kit webhook documentation lists the available event names.

For a first workflow, use a dedicated tag such as sms-reminder-approved. A dedicated tag is easier to test and audit than triggering on every new subscriber.

Create an n8n Webhook node first and copy its production URL. Then register that URL with Kit:

curl --request POST \
  --url https://api.kit.com/v4/webhooks \
  --header 'Content-Type: application/json' \
  --header 'X-Kit-Api-Key: YOUR_KIT_API_KEY' \
  --data '{
    "target_url": "https://n8n.example.com/webhook/kit-sms",
    "event": {
      "name": "subscriber.tag_add",
      "tag_id": 12345
    }
  }'

Replace the URL, API key, and tag ID. Keep the API key in your shell secret store or deployment environment, not in a shared script.

2. Validate the subscriber

Add an n8n Set or Code node that creates a predictable internal record:

{
  "subscriber_id": "kit subscriber ID",
  "phone": "+12025550123",
  "consent": true,
  "consent_source": "event registration form",
  "campaign": "event-reminder-2026"
}

Before the Twilio node, reject the item when:

  • consent is missing or false
  • the number is not in E.164 format
  • the recipient previously opted out
  • the same campaign and subscriber combination was already queued
  • the current time is outside the sending window you defined

Email permission and SMS permission are separate. A Kit subscriber should not enter this flow merely because they receive email.

3. Add an idempotency record

Webhooks can be retried. Your workflow can also be restarted manually. Without a unique record, either event can send the same text twice.

Create a key from:

campaign ID + subscriber ID + message version

Store the key before sending. If it already exists with a queued, sent, or delivered state, stop the duplicate run. A Postgres table, Redis key, or another transactional store works. A spreadsheet is acceptable for a small test but is easier to race under concurrent sends.

4. Send through a Twilio Messaging Service

Use n8n's Twilio node or an HTTP Request node that calls Twilio's Messages API. A Messaging Service is preferable to hard-coding one number because it centralizes sender configuration and opt-out behavior.

Map:

  • To from the normalized phone field
  • Body from an approved template
  • MessagingServiceSid from credentials
  • StatusCallback to a second n8n webhook

The first message should identify the sender and include the required opt-out instruction for your use case and region. Twilio's current Messaging Policy explains its consent and opt-out requirements.

Do not put account SIDs or auth tokens in Set nodes. Use n8n credentials and restrict who can edit or export the workflow.

5. Record delivery status

Twilio accepting a message does not prove delivery. Save the returned message SID, then update the record when the status callback arrives.

The callback workflow should:

  1. Match the Twilio message SID to the queued record.
  2. Store the new status and error code.
  3. Retry only temporary failures.
  4. Suppress invalid or opted-out destinations.
  5. Alert a person when failures cross a useful threshold.

Keep delivered and failed counts separate in reporting.

6. Handle replies and STOP

Configure the Messaging Service's inbound webhook. When a recipient opts out, Twilio can block later messages and notify your webhook of the opt-out type. The Twilio Messaging Services documentation describes standard and advanced opt-out handling.

Update your own consent ledger as well. Kit can remain the marketing profile, but the send decision should read the latest suppression state before every message.

7. Test the failure paths

Run at least these tests before enabling the Kit webhook for a real audience:

  • eligible subscriber receives one message
  • missing consent sends nothing
  • malformed phone number sends nothing
  • duplicate webhook sends only once
  • Twilio rejection records a failure
  • status callback changes queued to delivered or failed
  • STOP prevents another send
  • a workflow restart does not replay completed items

Save the test evidence with the workflow version. That makes later edits safer because you know what must still pass.

When a simple Zap is enough

Zapier or Make can be perfectly reasonable for one low-volume reminder. The same consent, opt-out, and delivery requirements still apply. Move to n8n or custom code when the workflow needs several branches, durable state, shared monitoring, or controlled retries.

For the architecture comparison, read three ways to send ConvertKit SMS with Twilio. If you want the workflow designed, tested, documented, and handed over, see my n8n automation consulting service.

All postsBook a Call