Getting Started with Twilio: Send Your First SMS from an Automation

The intro article made the case for why Twilio belongs in your stack. Now we build. By the end of this article, you’ll have a Twilio account, a real phone number, and a working n8n workflow that sends an actual SMS to your phone.

I’ll also cover the number one mistake that breaks Twilio integrations for beginners — phone number formatting — because I guarantee you’ll run into it if I don’t explain it here.

---

Setting Up Your Twilio Account

Go to twilio.com and click “Sign up for free.” You’ll create an account with your email address and verify it.

What you get on the free trial:

• $15 in account credit (enough to send roughly 1,800 SMS messages)
• A test phone number you can use immediately
• The ability to send SMS to verified numbers only (more on this below)
• Full access to the Twilio console and all features

The one trial limitation that matters: During the trial, you can only send SMS to phone numbers that you have manually verified in the Twilio console. This is a fraud prevention measure. You can verify your own phone and a few others to test with, but you cannot send to arbitrary numbers until you upgrade your account with a credit card.

This is a real constraint during development. Verify your own number immediately so you can test. When you’re ready to go live with real customers, add a payment method and the restriction is lifted.

Finding your credentials:

After account creation, you’ll land on the Twilio console home page. Your credentials are shown prominently:

• Account SID — a long string starting with AC...
• Auth Token — another long string, shown partially hidden

These two values are your Twilio credentials. Treat the Auth Token like a password — it authenticates every API request. Copy them somewhere secure (a password manager or your secrets manager, not a text file on your desktop).

---

Getting a Phone Number

Every SMS you send needs a “From” number — a real Twilio phone number registered to your account.

In the Twilio console, go to Phone Numbers → Manage → Buy a Number.

Choosing a number type:

• Local 10-digit number ($1.15/month): A standard US area code number, like (512) 555-1234. This is what most businesses should start with. Recipients recognize the format, it’s the cheapest option, and it works for most automation use cases.

• Toll-free number ($2.15/month): An 800/888/etc. number. No geographic association. Slightly easier to get approved for high-volume A2P messaging in some cases.

• Short code ($500–$1,000+/month): A 5–6 digit number (like 54321). Used for very high volume SMS like national marketing campaigns. Not what you need to start.

For SendJob and most field service automations, a local 10-digit number is correct. Pick an area code that matches your service area — it looks more professional to customers, and carrier filtering is slightly friendlier to local numbers sending to local recipients.

Search for available numbers in your area code, pick one, and click buy. It’s added to your account immediately.

Important note about A2P registration: If you’re in the US and plan to send business SMS at any real volume, you’ll eventually need to register your number and brand with carriers. This is called A2P 10DLC registration. I cover the full process in the advanced article. For now, buy your number and start building — you have time before registration is urgent.

---

The Twilio Console

Take five minutes to understand the layout before you start integrating.

Phone Numbers → Active Numbers: Where your numbers live. Click into a number to configure its webhook URLs — this is where you’ll point inbound SMS webhooks and voice call handlers.

Messaging → Logs → Messages: Every message you send or receive is logged here. When something goes wrong, this is the first place to check. You can see the message body, the status, the error code if it failed, and the carrier it was delivered on.

Messaging → Logs → Errors: Filtered view of only failed messages, with error codes and descriptions. The Twilio Error Lookup tool (searchable at twilio.com/docs/errors) explains every error code in plain English.

Monitor → Debugger: A higher-level view of errors and warnings across all Twilio products on your account. If something is broken and you can’t figure out why, check here.

Billing → Current Balance: Where you see your current credit and usage. Set up a billing alert so you get an email when your balance drops below a threshold — Twilio doesn’t automatically stop sending if you run out of credit, but you get warnings.

---

Phone Number Formatting

This is the number one reason Twilio integrations fail for beginners, and it’s completely avoidable once you know about it.

Twilio requires phone numbers in E.164 format. For US numbers, that looks like: +15551234567

• The + prefix is required
• The country code comes next (1 for the US)
• Then the 10-digit number with no spaces, dashes, or parentheses

What breaks it:

• (555) 123-4567 — Twilio will reject this
• 555-123-4567 — Twilio will reject this
• 5551234567 — Twilio will reject this (missing + and country code)
• 15551234567 — Twilio will reject this (missing +)

When you’re capturing phone numbers from form submissions, customer records, or webhook payloads, the format is almost never E.164. You need to normalize it before passing it to Twilio.

How to handle this in n8n:

Use a Code node or Set node between your data source and the Twilio node. Here’s a simple normalization in a Code node:

// Get phone from previous node
let phone = $input.first().json.phone;

// Strip everything that isn't a digit
phone = phone.replace(/\D/g, '');

// If it's 10 digits, assume US and prepend +1
// If it's 11 digits starting with 1, just prepend +
if (phone.length === 10) {
  phone = '+1' + phone;
} else if (phone.length === 11 && phone.startsWith('1')) {
  phone = '+' + phone;
}

return [{ json: { ...($input.first().json), phone_e164: phone } }];

After this Code node runs, use {{ $json.phone_e164 }} in your Twilio node’s “To” field. You’ll never see a phone format error again.

This is worth doing even if you think your data is clean. Users type phone numbers in every imaginable format, and a single malformatted number will fail silently if you don’t catch it.

---

Connecting Twilio to n8n

Setting up the Twilio credential in n8n takes about two minutes.

In n8n, go to Credentials → New Credential → Twilio. You need:

• Account SID — from your Twilio console home page
• Auth Token — from your Twilio console home page

Save the credential. Twilio will show as connected.

Send your first SMS:

1. Create a new workflow
2. Add a Manual Trigger node
3. Add a Twilio node
4. Set the credential to the one you just created
5. Set Operation to “Send SMS”
6. Fill in the fields:
   • To — your verified test phone number in E.164 format (e.g., +15551234567)
   • From — the Twilio phone number you bought (e.g., +15559876543)
   • Message — Hello from n8n and Twilio! This is your first automated SMS.
7. Execute the workflow

Your phone should receive the message within a few seconds. If it doesn’t, go to the Twilio console → Messaging → Logs → Messages to see what happened. The error code will tell you exactly what went wrong.

---

Adding Twilio to a Real Workflow

Sending a test SMS is satisfying but not useful. Let me show you how this fits into a real automation.

If you’ve built the lead capture workflow from the n8n walkthrough series, you already have a workflow that:

1. Receives a webhook when a lead fills out a form
2. Saves the lead to Supabase
3. Sends a confirmation email via Resend

Now add SMS confirmation to that workflow.

After the Resend email node, add a Twilio node:

• To — {{ $('Webhook').item.json.body.phone }} (or wherever the phone number lives in your webhook payload — check the upstream node’s output)
• From — your Twilio number
• Message — Hi {{ $('Webhook').item.json.body.name }}, thanks for reaching out. We'll be in touch within 24 hours. — SendJob Team

Add the phone number normalization step I described above between the webhook and the Twilio node if your form doesn’t enforce E.164 format (it almost certainly doesn’t).

Run a test submission. Within a few seconds, the lead should receive both an email and an SMS confirmation. From a customer experience standpoint, that’s a significant upgrade — they know the form went through, they have a record of it on their phone, and the response feels immediate and professional.

---

Understanding Delivery Statuses

When you send an SMS through Twilio, the message doesn’t go from sent to delivered in one step. It moves through a sequence of states:

queued — Twilio has accepted the message and is ready to send it. It hasn’t left Twilio yet.

sending — Twilio is transmitting the message to the carrier.

sent — Twilio has handed the message off to the carrier. This is as far as Twilio’s direct responsibility goes.

delivered — The carrier has confirmed delivery to the recipient’s handset. This is the status you actually want to see.

failed — Twilio couldn’t send the message. Usually a configuration error — bad phone format, invalid credentials, insufficient balance.

undelivered — Twilio sent it but the carrier reported it couldn’t be delivered. Common causes: the number is invalid, the recipient’s phone is off and out of range, or carrier filtering (the message was flagged as spam).

The important thing to know: you won’t see “delivered” status unless you’ve configured a status callback webhook. By default, Twilio sends the message and you get “sent” — you don’t automatically receive the carrier’s delivery confirmation.

In the Twilio console message logs, you can see the status for each message manually. But for automated delivery tracking — updating a delivered flag in Supabase, knowing when to follow up on undelivered messages — you need to configure a status callback. The advanced article covers exactly how to set that up.

For now, understanding these statuses prepares you to interpret the logs correctly and know what you’re looking for when things don’t behave as expected.

---

Trial Account Limitations and Upgrading

While you’re on a trial account, every message you send will include the prefix “Sent from your Twilio trial account -” before your message body. Customers will see that text. It makes your automations look unfinished.

Additionally, as I mentioned, you can only send to verified numbers during the trial.

To verify a number: In the Twilio console, go to Phone Numbers → Verified Caller IDs → Add a new number. Twilio will call or text the number to confirm you have access to it. Once verified, you can send to it from your trial account.

To upgrade: Go to Billing → Upgrade → add a credit card. Your trial credit rolls over. The prefix is removed. The verified-numbers restriction is lifted. You can now send to any valid phone number.

Most builds should upgrade before they go live with real customers. The trial prefix alone is reason enough — but more importantly, restricting yourself to verified numbers means you can’t actually run the automation with real customers unless they’ve all been manually verified first.

---

When you’re ready to go deeper — inbound SMS, delivery tracking, and two-way flows — Advanced Twilio → covers it all.