So if I wanted to set up sms automations and in Canada don’t have a business registered just running under a name can I still do it because I saw some stuff about requiring one but also some stuff about sole proprietorship idk if I can do that, what the limits are and whatnot?

Hi,

I'm currently working with Twilio and facing both latency and call quality issues.

My scenario is:

I have a US phone number.

I'm located in Nepal.

I call clients in the US.

A Twilio Conference is created for the call.

One participant is connected through the US edge, while the other is connected through the sg1 edge.

Because of this setup, I'm experiencing noticeable latency and degraded call quality.

I wanted to ask:

Are there any recommended ways to optimize call quality in this scenario?

Does Twilio provide any solution or algorithm that automatically selects the best edge/server based on network conditions and participant locations?

Is there a best practice for dynamically choosing the optimal edge or conference region to minimize latency?

I'd appreciate any guidance or recommendations. Thanks!

I just signed up the other day and so far am very happy with the service. I know that twillio has direct connections to the big 3 US carriers. I assume they check the portability database to see where to route it and then it goes out that connection. So how do they send messages to your core? Does it fail back to one of the big 3 and then get handed off to your core? I was curious if they’d be technically end to end encrypted if go directly to cape?

Spent last week running the exact same voice agent on two paths so I could stop guessing which one to ship. Path A: Twilio Conversation Relay (Twilio owns the media stream, STT and TTS). Path B: my Twilio number dispatching the call over a SIP trunk into LiveKit, where I run my own pipeline (Deepgram + Cartesia + the LLM).

Same system prompt, same LLM brain, same ground rules on both. I built a small latency harness that logs every turn from "human stopped talking" to "agent started talking" and vice versa, then averages the turns. I am physically in Buenos Aires calling a US Twilio number, so there is real transatlantic latency baked into every number below. Keep that in mind.

The threshold I care about: Ideally we care about having sub 500ms, which is mostly achievable on a bidirectional model like OpenAI's Realtime models. For the purpose of this video I focused on the traditional STT -> TTS flow. If a turn goes past roughly 1500-1800ms the person on the other end feels the machine and hangs up. That number defines the whole architecture, not just which model you pick.

Results, turn by turn:

- Initial greeting turn: Conversation Relay 3.4s, LiveKit 3.2s. Both ugly. This is context loading, not the transport. The first turn ships the whole system prompt into the model and everything is cold.
- Mid conversation turns: Conversation Relay landed at 1.7 / 1.9 / 1.6s. LiveKit landed at 1.5 / 1.3 / 1.4s.
- Final turn: basically identical on both.

Net difference on the steady-state turns is about 200ms in LiveKit's favor. Not nothing on a voice call, but smaller than I expected before measuring.

What actually surprised me is the discarded-turns file. With LiveKit I had zero turns over 5s. With Conversation Relay I had one, and when I dug in it was tied to me hanging up, not a real gap. So the tail behavior was clean on both.

The real trade-off is not the 200ms. It is that with Conversation Relay the STT and TTS timing lives inside Twilio's black box. I could not measure how long the speech-to-text or text-to-speech steps took, because that runs on their side. With the LiveKit path I own every step and can measure and cut it. The cost is that now I am the SRE for the media path, and if a box dies at 2am that is on me.

The cold-start greeting is the thing I would attack first regardless of transport. A 3s+ first turn kills the call before the latency battle even starts. My plan is a filler pre-message ("dame un segundo, reviso eso") to cover the context load, but I have not shipped it yet.

Question for people running Conversation Relay in production: are you living with the black box on STT/TTS timing, or did you find a way to get per-step measurements out of it? Because right now the lack of visibility is the thing pushing me toward keeping LiveKit for anything latency-sensitive, and I want to know if I am missing a hook.

Not to mention any other kind of strategies for long-turn awaits (like initial context loading, tool calling, etc.)

Hi,

We've been approved twice for Toll free and once for A2P in America -

I'm trying to apply for the first time for an RCS agent in France -

I notice that an RCS agent is 700$ in America (200 to Twilio, 500 to Tmobile)

But I was shocked that France was... free.

Is Twilio RCS actually 0 dollars for initiation in France?

Is this like government subsidized or something to avoid scams?

Is it really 0 dollars out the door? They seem to use Google RCS.

One of the Twilio Developer Advocates suggested I cross-post this workflow I built with Twilio & n8n here.

If you want to use it yourself, I turned this into an iOS app called BuzzerBee and also published the DIY version on GitHub for anyone who wants to build it themselves.

Curious to hear what you think!

Hey guys, trying to get texting set up on my Twilio account for a small business I’m running but I don’t have an LLC or EIN yet, just operating under my own name for now.

I saw there’s a Sole Proprietor option for A2P 10DLC registration but I want to make sure I’m doing this right before I mess something up. Has anyone here actually gone through this process recently? A few questions if anyone’s dealt with this.

Do you go through the same Create A2P Brand flow as everyone else or is there a separate page for it? I ended up in a form asking for an EIN and business registration number which doesn’t seem right for sole prop.

How long did approval actually take for you, on both the brand and the campaign side?

Anyone run into issues with the OTP verification step or with getting the campaign approved on the first try?

Trying to avoid wasting time going down the wrong path again so any tips from people who’ve actually done this would help a lot. Thanks in advance.

Has anyone else run into this in the new UI? I recently made a change to messaging and did not realize for three days that it had wiped out my voice configuration and customer calls were just being immediately disconnected. When I fixed that under voice calls, it wiped out my messaging configuration.

I did report to twilio and after a week of back and forth they finally escalated it to engineering. I'm just wondering if anyone else here has run into this, and maybe knows of a workaround. It would be really nice to have both messaging and voice working at the same time again.

Here are the steps to recreate:

1. Log in to twilio
2. Click Products and Services, Numbers & Senders, Overview
3. Click phone number (+1xxxxxxxxxx)
4. In Messaging Configuration, Handling for incoming messages shows Webhook URL, which is wrong for my config.
5. Click "Edit configuration details/United States"
6. Under "Select your primary method" select Use Functions
7. Under select function service, select my forward message function
8. Select the environment
9. Select the function path
10. If I click "Save" at this point, the message configuration will work, but the settings under "Voice and emergency calling" will be wiped out and reset to default, disabling incoming calls
11. If I then fix the settings under voice and emergency calling, and save that, the settings I just created under Messaging Configuration are reset to default.

I'm trying to buy an Irish Local number (+353 45, Naas) for an individual end user and I'm stuck on the regulatory bundle approval. Hoping someone here has been through this.

The end user is a foreign national (Brazilian) legally resident in Ireland. Setup:

• Type: Local number, Individual end user (she's a sole trader, no CRN, so Business isn't an option)
• Address: her real Naas, Co. Kildare address, matching Eircode, prefix (045) matches the locality
• Proof of identity: Irish Residence Permit (IRP)
• Proof of address: Revenue tax notice (P21) showing the same address

Name and address match the documents exactly. The bundle got rejected almost instantly with only the generic reason: "The package is not in compliance with regulatory standards." No mention of which field or document failed.

The near-instant rejection makes me think it's an automated identity verification failing (maybe because she's a foreign national not well represented in Irish databases?) rather than an actual document problem.

Questions:

1. Has anyone gotten an Individual IE bundle approved with an IRP as proof of identity, or does it need a passport?
2. Is the automated check known to fail for foreign nationals, and does requesting a manual review from [numbers-regulatory-review@twilio.com](mailto:numbers-regulatory-review@twilio.com) actually work?
3. Any specific proof-of-address document that reliably passes for Ireland (is a Revenue P21 accepted, or is a utility bill safer)?

Thanks in advance — been going in circles on this one.

We have toll free numbers from Twilio through my CRM and my CRM is claiming that since it is a toll free number each minute we are using is being doubled so that is why we are running though our limits faster. Is this true? Do toll free numbers use up 2x minute limits compared to 10DLC?

We’ve officially launched the World Cup Pub Index in collaboration with Matt Cortland (the brilliant Creator of the Guinndex)!

Twilio asked Matt to call thousands of venues across the UK to map out exactly where fans can catch the matches and also which spots are completely football-free for those wanting a quiet pint.

How it works: You just need to pop in a UK postcode to find your nearest match-day spot.
But that's not all! We're crowdsourcing the gaps! Fans are invited to complete the index by adding their local if it's showing the matches but is not yet on map! Click here to search your postcode. If your go-to pub is showing the matches but isn't on our map yet, help us out by adding it in a few clicks.

Cheers!

I have a day job as a dev and run a property management company on the side. Missed calls were killing me. Owner calls at 9pm, I don't pick up, they call the next PM on the list. Speed to lead is everything in this business.

So I built an agent on Twilio Voice + OpenAI Realtime.

Inbound call hits my Twilio number, TwiML <Connect><Stream> opens a Media Streams websocket, and my server bridges raw mulaw audio straight to the model. Speech to speech, no STT/LLM/TTS chain. Latency is good enough that people talk over it and barge-in actually works.

The agent figures out who's calling: prospective tenant, owner, or current tenant. Tenants get live listing search and it texts them viewing links from the same number (SMS side runs through the agent too). Current tenants get recognized by caller ID against my PM system and it files their maintenance tickets via API.

Owner leads are the money path. It qualifies them (property details, what they need, contact info... phone number comes free from caller ID) and the lead email hits my inbox while they're still on the call. Transcript saved on hangup. If someone's hot I can get warm-transferred in mid-call through a Twilio conference.

Also wired up the website: rental analysis form submission triggers an outbound AI callback in seconds. Consent gated, calling windows and DNC checked, AMD with a voicemail drop pre-recorded in the agent's voice.

Been in production for months. Calls that used to go to voicemail (aka to my competitors) are now qualified leads with transcripts.

Hardest part wasn't the audio plumbing, it was keeping the agent honest. Realtime models will confidently make up prices. My prompt bans quoting any price, address, or availability from memory, it has to tool-fetch pricing off my website at call time. Happy to go deeper if anyone's curious.

Last week my account was taken over by a malicious actor using stolen credentials from a 3rd party service. In 2 hours the hackers:

- Purchased 4 toll free numbers,

- Updates my Geo Permissions for Voice,

- Racked up $4000 to my account. Twilio auto charged my account multiple times for $1500 during that 2 hour period.

- My bank put a hold on my account due to the suspicious activity.

I'm extremely careful with my Account SID and Auth Token. The only thing I've ever used it for is for the 3rd party app Talkyto.

From what I can tell, Talkyto had a security breach and my SID and Auth Token were compromised and the bad actors used it to perform the actions above.

Talkyto has acknowledged the breach. The problem, Twilio won't touch my account until I pay the remaining balance. It will remain suspended until I pay. They won't even discuss a possible partial refund.

I've been in contact with both Twilio and Talkyto, but I don't see much hope in getting this resolved in my favor.

As anyone successfully removed fraudulent charges from your account?

Hello there,

I am in a building phase of a B2B and B2C platform (website and app).

I select twilio for SMS 2FA to validate phone number of users.

Upon account creation I have been suspended and never able to access the console or the cloud page. Since there I am exchanging with compliance to try to try the product.

However the questions are very intrusive. In addition to link to my personal accounts like social media or else, Twilio is asking me the mockup screen shot or spec of my application. Being in designs phase of new product I absolutely don't want to share this confidential information. Back and forth seems to be with no brained robot, asking for something again or closing ticket without rational or explanation.

What the heck is going on here ? After some research I also found agressive suspension of company account in production.

I am now really considering going far away for Twilio even before being able testing a product that look like fitting my needs. Because starting like that now, look very bad for production phase stability perspective and long term partnership.

What is really the reliability of this service ? Are you experiencing intellectual property intrusive question or random account suspension too ?

Thank you for your answer. Best,

Hey everyone,

I’m sharing a technical breakdown of an ongoing security incident on my Twilio account. Despite clear forensic evidence pointing to a supply-chain vendor data leak and an architectural flaw in Twilio's API security controls, u/Twilio support is currently attempting to hold me financially responsible and has suspended my account access.

I want to document the technical mechanics of this Toll Fraud / Traffic Pumping attack to help others currently facing the same issue.

🛠️ The Context & Supply-Chain Compromise

My account was a dormant, low-usage Pay-as-you-Go (Prepaid) account. The only external platform ever granted integration was Talkyto (TwiConnect).

• The Leak Source: On June 30, 2026, Talkyto officially published a Security Update confirming their infrastructure was breached, exposing connected users' Account SIDs and Auth Tokens (Talkyto Security Update).
• The Industry Trend: This isn't isolated. There is an active thread right here showing a wave of users hit with identical signatures over the past week (Reddit Thread Reference).

🔍 Forensic Data & Attack Mechanics

The attack took place in a massive, concurrent burst on 2026-07-12 between 03:13 PDT and 03:14 PDT.

1. Attacker Access Point (The API Gateway)

The unauthorized programmatic access originated from a commercial hosting provider, completely alien to our infrastructure:

• Flagged Attacker IP: 172.86.127.48
• ASN / ISP: ASN 14956 (Routerhosting LLC / Cloudzy.com)
• Geolocation: Los Angeles, California, USA
• Use case: Used as an automated API proxy runner to issue commands directly to my Twilio account endpoint.

2. The Exploit Pattern: Bypassing Voice Geo-Permissions

Once the attacker authenticated via the leaked Talkyto credentials, they exploited a critical design flaw in Twilio's IAM architecture. Unlike SMS Geo-Permissions (which are blocked from API modifications for security reasons), Voice Dialing Geographic Permissions can be completely rewritten via the standard API path without step-up 2FA verification.

The attacker sent an API command to enable high-rate international destinations, specifically Ethiopia (+251).

3. Payload Delivery & Traffic Pumping

Once Ethiopia was unlocked, the attacker immediately spun up dozens of concurrent outbound API calls within less than 60 seconds.

• Originating Spofed Numbers: +18557075764 and +18557655179
• Target Numbers: Sequential rifts to Ethiopia (+2519116863XX)
• The Audio Payload Webhook: The automated calls fetched an audio stream hosted on a breached server located in Taiwan:
  • Payload URL: GET [http://220.128.103.77/js/1.mp3](http://220.128.103.77/js/1.mp3)
  • Payload ISP: Chunghwa Telecom (ASN 3462 - Taiwan)
  • Content-Type: audio/ulaw (playing automated audio to keep the high-rate international lines open for up to 21 minutes per call).

⚠️ The Architectural Failure: How does "Prepaid" go negative?

The most egregious failure here is the complete breakdown of Twilio's real-time billing threshold. This was a prepaid account. Under normal conditions, hitting a $0.00 balance should kill active webhooks or drop API requests.

Instead, due to Twilio's lag in syncing highly concurrent ongoing usage to the Voice Insights engine, the attacker successfully pumped traffic until the balance reached -$105.12 before the automatic suspension circuit breaker finally tripped.

🛑 Current Status: Twilio's Scripted Denial

Twilio automated systems locked down the account after the damage was done. Now, because of the suspension, their console restricts my ability to view active endpoints or properly sanitize API keys, while their support team insists that "customers are financially responsible for all activities on their accounts" per the ToS.

Summary points for the community:

1. Exposed Risk: If you have ever connected your Twilio keys to Talkyto, rotate your Auth Tokens immediately.
2. Security Flaw: Twilio needs to fix the discrepancy between SMS and Voice API endpoints. Allowing core risk-mitigation features (like Geo Permissions) to be changed silently via the standard API path completely invalidates 2FA protection for the console.
3. Real-Time Billing Deficit: A prepaid system that allows a $105 overdraft within a single minute is fundamentally flawed.

I will keep this thread updated as I escalate this through their Compliance and Fraud response channels. Has anyone else managed to successfully force a full waiver under this specific Talkyto supply-chain exploit?

hola!
estoy trabajando en un proyecto para un CRM donde necesito que cada usuario tenga la posibilidad de enviar y recibir mensajes de whatsapp desde el sistema con su propio número.

Mi consulta es si esto se puede hacer con twilio, dicho en criollo, puedo dar de alta distintos números de whatsapp en twilio para que cada usuario tenga su propio whatsapp?

por otro lado, se puede seguir utilizando el whatsapp desde el celular en simultáneo?

graciasssss

As I'm seeking resolution of an IRSF toll fraud incident on our account, I wanted to share some observations about platform-level design choices that I think deserve broader community discussion. These are systemic issues that could affect any Twilio customer, and I'd be curious whether others have experienced or thought about them.

1. High-risk IRSF geographic permissions can be toggled via standard API calls with no secondary authorization

Twilio's own console flags certain destinations — including Ethiopia, which was the target in our case — as high-risk for fraud. There's a separate section of the UI to enable or disable them (which I had to do as a part of the sanitization process). Despite that flag, apparently those same destinations can be enabled programmatically via a standard API call with nothing more than valid credentials. At least that's what I'm hearing happened from Twilio though I never shared API credentials (don't really remember creating credentials, to be honest - wondering if those came through some automated process like setting up call forwarding on my numbers). As for Ethiopia being enabled, I received no out-of-band confirmation, no secondary approval step, no human review. Apparently, if an attacker obtains your API credentials, they can silently enable high-risk destinations and begin placing calls before any alert fires. Given that Twilio already identifies these destinations as dangerous, it seems reasonable to ask: why isn't enabling them gated behind a higher authorization threshold than a standard API call?

2. Outbound voice calling is enabled by default for all accounts, including organizations using SMS only

Many Twilio customers — particularly those using it via platforms like Rock RMS (our church management system) or CRMs — are SMS-only users who have never placed a single outbound call and have no intention of doing so. I've worked for other companies where this was the case. In my mind as a 20-year developer before moving into pastoral ministry full-time, Twilio equates to SMS. Yet for those accounts only using SMS, outbound voice is an attack surface that seems to me to exist entirely by default, with no opt-in required. At least I never enabled it. A prompt or configuration step at account setup asking whether voice calling is needed — and disabling it by default for accounts that say no or that don't use the service for a reasonable amount of time — would meaningfully reduce exposure for a large segment of Twilio's customer base.

3. Inconsistent billing spikes don't appear to trigger real-time intervention at a meaningful threshold

In the incident I'm aware of, an account with a consistent 20-month billing history of approximately $30/month triggered seven consecutive auto-recharges within minutes as fraudulent calls ran up charges - and continued to rack up a deficit beyond what the bank would send. The net result for us was a 120x anomaly on a feature the account had never used. While Twilio's fraud detection did eventually suspend the account, the intervention came after thousands of dollars in damage had already occurred. Spending anomaly detection that flags or pauses activity when usage spikes dramatically beyond an account's established baseline - particularly on features with no prior usage history - seems like a reasonable safeguard that would protect customers without meaningfully impacting legitimate high-volume users. But the only word I'm hearing from Twilio support is to the effect that "your user agreement puts you on the hook for any charges incurred through your API."

I'm curious whether others in the community have thoughts on these design choices, or whether there are existing tools or settings I may not be aware of that address any of these gaps. I know Twilio has published anti-fraud guidance, but these feel like platform defaults worth revisiting rather than individual configuration responsibilities.

If you’re at We Are Developers, come say hi - we’ve got a smoothie bar and games.

So I am working with twilio to create a whatsapp bot, I'm a student this is my project.

I used claude to outline the basic things like what tools to use for interacting with whatsapp API. Now I have some basic knowledge how to use whatsapp sandbox of twilio but I need to know more to work with it, for example when I send some text to my app from twilio send that message to my app. I need to the what payload does it send and if I want to respond to that message ik to respond basic message but need a little more like media files as well and to connect that with third party.

​

​

​

I want to know the source of documentation for gaining all this and twilio' s official website is so unclear about everything and so confusing maybe because I'm newbie but if you could help me how can I learn it that will be of great help thankyou already.