Kit, formerly ConvertKit, can supply the audience event for an SMS workflow. Twilio can send the message. The missing piece is the control layer between them: it checks SMS consent, stops duplicates, respects opt-outs, records delivery state, and decides whether a failed item is safe to retry.
That distinction matters more than the connector you choose. A one-step new Kit subscriber -> send Twilio SMS automation can produce a successful test while still having no reliable answer for a recipient who opts out, a webhook delivered twice, or a message that Twilio accepts but never delivers.
If you only need the node configuration, use the separate Kit-to-Twilio n8n walkthrough. This guide is for choosing the production architecture.
The production split: audience, decision, transport
A reliable ConvertKit SMS workflow gives each system a narrow job.
| System | What it should own | What it should not be trusted to infer |
|---|---|---|
| Kit | Subscriber identity, forms, tags, segments, purchases, and audience events | SMS permission, final delivery, or whether a retry is safe |
| Control layer | Consent evidence, eligibility, suppression, deduplication, approval, queue state, and reporting | Carrier delivery without a Twilio callback |
| Twilio | Sender configuration, message submission, carrier-facing status, replies, and opt-out handling configured for the sender | Your campaign rules or the meaning of a Kit email subscription |
The flow should therefore look like this:
Kit webhook or connector trigger
↓
Verify event and reject duplicates
↓
Check SMS consent and suppression
↓
Create one approved queue item
↓
Send through Twilio
↓
Store initial response and Message SID
↓
Process delivery and inbound reply webhooks
↓
Update suppression, Kit state, and campaign report
This model works whether the control layer is a Zapier table, an n8n workflow with a database, or a custom application. The implementation changes. The ownership rules do not.
Use Kit's current webhook endpoint
Kit's previous create-webhook route still works for existing integrations, but Kit now labels it legacy. New integrations should use the current webhook endpoint API. One endpoint can subscribe to several event types and returns a signing secret for verification. Kit also documents retry behavior for webhook delivery.
Two consequences follow.
First, verify the webhook signature before using the payload. A public endpoint that accepts an unsigned subscriber event lets an outside caller create work in the SMS queue.
Second, make event processing idempotent. A retry must not create a second message for the same campaign and subscriber. Store a stable key before the send step, such as:
campaign_id + subscriber_id + message_version
If the same Kit event arrives again, the workflow can return the existing queue item instead of scheduling another text.
An email subscriber is not an SMS consent record
Kit can tell you that someone joined a form or received a tag. That fact does not describe what they agreed to receive by text.
Twilio's current Messaging Policy requires prior express consent and proof of that consent. The policy also limits consent to the sender and message subject disclosed to the recipient. Promotional messages have a stricter written-consent requirement under the policy.
Keep a separate record with the facts needed to make a send decision:
| Field | Why it exists |
|---|---|
| Subscriber ID | Links the decision back to the Kit record |
| Normalized phone number | Gives Twilio an unambiguous destination |
| Consent status | Allows or blocks the send |
| Consent timestamp and source | Shows when and how permission was collected |
| Sender and message subject | Keeps the send within the permission that was given |
| Policy or disclosure version | Shows what the recipient saw |
| Opt-out timestamp | Stops later queue items |
Store phone numbers in E.164 format. An input such as 2025550123 has no country context and should not enter the send queue until it has been normalized or reviewed.
This is implementation guidance, not legal advice. Messaging rules also vary by jurisdiction, sender type, carrier, and use case.
Choose the route by the state it must own
Zapier or Make for one narrow notification
Zapier or Make can be sufficient when one Kit event leads to one low-frequency notification, the eligibility rule is simple, and someone reviews failed runs.
The workflow still needs a consent lookup before Twilio and an inbound path for replies and opt-outs. It also needs a stored deduplication key. Without those controls, adding more filters to the outbound path only makes an incomplete design harder to inspect.
Move beyond this route when you need several campaign types, scheduled sending windows, a durable queue, different retry rules, or reliable campaign reporting.
n8n for queues, branches, and callbacks
n8n is a better fit when the workflow must coordinate several states rather than perform one action. A production design usually separates intake, eligibility, sending, delivery callbacks, and inbound replies into distinct workflows.
That separation lets you pause the sender without losing Kit events, replay a failed callback without sending again, and route permanent failures to review instead of retrying every error.
Keep the state outside individual node executions. A small database table can hold the campaign ID, subscriber ID, consent decision, idempotency key, Twilio Message SID, current status, attempt count, and next eligible retry time. The n8n production readiness checklist covers the release controls around that design.
Custom code for a shared campaign system
A custom application becomes reasonable when several people need to preview an audience, approve a campaign, version templates, select senders by country, inspect live failures, and export an audit record.
This is also the route where Twilio's Bulk Messaging API may fit. Twilio currently describes it as public beta, with no SLA, and allows up to 10,000 recipients in one request. A successful request returns 202 Accepted with an operation ID.
That response means Twilio accepted the batch operation. It does not mean 10,000 messages were delivered, and it does not prove that any recipient was eligible. The application still needs to reconcile the operation and message events, preserve suppression state, and decide what can be retried.
For most n8n workflows, one approved queue item per recipient is easier to reason about than a bulk operation. Use the bulk API when the application already has campaign approval, audience review, and operation-level reconciliation.
A successful API call is the start of delivery tracking
Twilio's status callback documentation makes an important distinction. A message sent through a Messaging Service starts in accepted state for immediate sending. Twilio does not send a callback for that initial state, so the application must store the API response and Message SID itself.
Later callbacks report transitions such as:
queuedsentorfaileddeliveredorundelivered
Report those states separately. A dashboard that counts every accepted request as delivered hides carrier filtering, invalid destinations, and sender configuration failures.
Retry rules should follow the state. A temporary service failure may be eligible for another attempt. An invalid number, an opt-out, or a message already accepted under the same idempotency key should not be sent again automatically.
Opt-outs have to stop work already in the queue
Twilio Messaging Services can process standard opt-out keywords. Its Advanced Opt-Out documentation explains that the feature is disabled by default, applies across the sender pool once enabled, and sends an OptOutType value to the inbound webhook when it handles a keyword.
Twilio can block later sends to that number, but the control layer still needs its own suppression state. Consider the sequence:
- A Kit tag creates 500 eligible queue items.
- One recipient receives the first message and replies
STOP. - Four more items for that recipient already exist in future campaigns.
The inbound webhook should update suppression before another worker selects those items. Relying on Twilio to reject them later creates avoidable failures and leaves Kit or another reporting system with stale eligibility.
When OptOutType is present, Twilio has already handled the standard confirmation response. Record the change and stop future work. Do not send a second automated confirmation from the workflow.
Test the failure paths before launch
A production test should prove more than one successful SMS. Verify that:
- An invalid Kit webhook signature is rejected.
- The same Kit event delivered twice creates one queue item.
- A subscriber without the required SMS consent never reaches Twilio.
- The initial Twilio response and later status callbacks update the same message record.
- An opt-out suppresses items that were queued before the reply arrived.
- A permanent failure enters review instead of an unlimited retry loop.
Use test recipients and the sender configuration appropriate to the destination country. For US application-to-person traffic over 10-digit long-code numbers, review Twilio's current A2P 10DLC requirements before production sending.
The smallest reliable choice
Use the least complex route that still owns the required state. A single reminder can remain in Zapier or Make. A queue with callbacks and recovery usually belongs in n8n. A shared campaign product with approvals and bulk-operation tracking may justify custom code.
The wrong shortcut is treating the first successful send as proof that the system is finished.
For the concrete webhook and node setup, continue with how to connect Kit to Twilio with n8n. If the workflow needs a queue, callback handling, monitoring, and an operator handoff, see n8n automation consulting.
Questions about ConvertKit SMS and Twilio
Can Kit send an SMS through Twilio?
Yes. A Kit webhook or connector event can start a workflow that creates a Twilio message. The workflow should verify the event, check a separate SMS consent record, and stop duplicate or suppressed items before the Twilio step.
Is a successful Twilio API response the same as SMS delivery?
No. Store the Twilio Message SID and initial response, then process later status callbacks until the message reaches a final delivered, undelivered, or failed state.
Should I use Twilio's Bulk Messaging API with n8n?
Usually not for a basic n8n queue. The API is currently public beta and returns an operation that still needs reconciliation. Use it when the surrounding application already supports campaign approval, consent and suppression checks, and operation-level tracking.
Where should SMS opt-outs be stored?
Store suppression in the control layer that decides eligibility, then reflect it in Kit or any other system that needs the state. Twilio can block later sends, but your queue should stop the work before another API call is made.