How to migrate from Twilio to Telnyx in n8n
Porting numbers, remapping the send API, and rewiring inbound webhooks — including the Ed25519 signature scheme and 10DLC re-registration that trip up most migrations.
Skip the rewiring. Download the n8n workflow JSON — a Telnyx send node, an inbound webhook with payload normalization, delivery-receipt handling, and a signature-verification stub. Import it, drop in your API key and Messaging Profile ID.
What actually changes
Twilio and Telnyx do the same job — programmable SMS and voice over an HTTP API — but they're not drop-in compatible. Migrating an n8n automation from Twilio to Telnyx is three distinct pieces of work: porting the numbers, remapping the send API, and rewiring inbound webhooks (including a different signature scheme). Do them in that order and the cutover is boring, which is what you want when live messaging is on the line.
I moved a production telephony pipeline off Twilio on CloserIntelligence for exactly this reason — the per-message and per-number economics at volume. The API surface is similar enough that most of the migration is mechanical; the parts that bite are the signature verification and 10DLC, covered below.
Prerequisites
- A Telnyx account with a Messaging Profile created
- Your existing Twilio numbers and the n8n workflows that use them
- API v2 key from Telnyx (Portal → Auth → API Keys)
- n8n reachable on a public URL for inbound webhooks
Step 1: Port the numbers (or run parallel first)
- In Telnyx, start a port request with your numbers and a recent Twilio bill/CSR as proof of ownership
- Porting takes days, not minutes — don't release the Twilio numbers until the port completes
- Safer path: buy one Telnyx test number first, migrate the workflow logic against it, and only port production numbers once the pipeline is proven
Step 2: Remap the send API
Twilio's send is a form-encoded POST to /Messages.json with From/To/Body. Telnyx is a JSON POST to /v2/messages with from/to/text and a messaging_profile_id. In n8n, swap the Twilio node (or HTTP Request) for an HTTP Request node configured like this:
POST https://api.telnyx.com/v2/messages
Headers:
Authorization: Bearer KEY0123... // Telnyx API v2 key
Content-Type: application/json
Body:
{
"from": "+1XXXXXXXXXX",
"to": "+1YYYYYYYYYY",
"text": "Your message",
"messaging_profile_id": "abc-123"
}Store the API key in an n8n Header Auth credential, not inline. The response shape differs too: Telnyx returns the message under data.id with a data.to[].status, where Twilio returned a flat sid and status. Anything downstream that read sid needs updating.
Step 3: Rewire inbound webhooks and delivery receipts
Point your Telnyx Messaging Profile's inbound and delivery webhook URLs at your n8n Webhook node's Production URL. Telnyx sends inbound messages and delivery status as JSON events (event_type: "message.received" / "message.finalized"), nested under data.payload — a different shape from Twilio's form-encoded inbound POST. Normalize the payload in a Code node right after the webhook so the rest of the workflow doesn't care which provider sent it. Same normalization discipline as the GHL webhook pipeline.
Step 4: Verify webhook signatures
This is the piece people skip and regret. Twilio signs with an X-Twilio-Signature HMAC over the URL + params. Telnyx signs differently: an Ed25519 signature in Telnyx-Signature-Ed25519 with a Telnyx-Signature-Ed25519-Timestamp, verified against your account's public key. You can't port the Twilio verification code — you rewrite it. Verify the signature before trusting any inbound event, or anyone who finds your webhook URL can inject fake messages.
Step 5: Cutover checklist
- Telnyx test number sends and receives through the rewired workflow ✓
- Delivery receipts land and update your records ✓
- Signature verification rejects a tampered payload ✓
- 10DLC brand + campaign registered and approved (US traffic) ✓
- Port production numbers, flip the send node, monitor the first hour closely ✓
- Keep the Twilio credential in place for one billing cycle as a rollback path ✓
Common gotchas
1. 10DLC registration. US A2P traffic on Telnyx needs its own brand and campaign registration — your Twilio 10DLC approval does not transfer. Start this early; approval can lag the number port.
2. Delivery receipts are a separate event. Telnyx sends the send-response and the final delivery status as two different webhook events. If you treated Twilio's synchronous status as final, you'll now under-report failures until you wire the message.finalized event.
3. Media (MMS) URLs. Telnyx expects media as a media_urls array of publicly reachable URLs, and inbound media comes back as time-limited links — download and re-host anything you need to keep, don't store the Telnyx URL.
4. Number format. Telnyx is strict about E.164 (+1XXXXXXXXXX). Twilio was more forgiving. Normalize numbers before sending or you'll get 422s.
Running this at volume? The n8n production reliability checklist covers retries, dedupe, and error workflows for a messaging pipeline.
Need this workflow customized or debugged? Book a 30-min scope call →
Stuck configuring this workflow?
I build and fix n8n workflows for agencies and SaaS teams. 30-minute scope call — bring the problem, leave with an estimate.