As the title says I don't have a registered business so making outbound calls to us numbers is restricted for me. What I wanna ask is: is sms also restricted? Or have a limit on how many sms can I send? (Even tho i am toll free verified).
Does anyone know anybody who can build a simple interface to dial?
I am tired of using my flows to dial, it takes a while.
I’m getting some quotes from Fiverr, but maybe anyone here knows someone?
Or even how to do it?
Need better call/sms rates from twilio, if i can get in touch with sales, that’ll be great!
I have developed a custom CRM specifically designed for real estate professionals to effectively manage their leads and business operations.
A significant portion of real estate agents utilize ads wit cta to WhatsApp to expedite the lead-to-response process.
My objective is to implement a feature within the CRM that enables the tracking of each lead who initiates a text message to WhatsApp, including their phone number and relevant information.
Could this functionality be achieved through the use of Twilio as middle man ?
Hi Twilio, please revert the UI. Thanks.
Long short story, I am trying to add an AI agent to the SMS of my office in order to give appointments to clients based on availability (maybe through a sharepoint list). The problem is, that the existing number that we already use ACTIVELY is from Simple Texting.
Can I change the number created and used in Simple Texting to Twilio?
I would be so so so so grateful if someone can help me…
Shipped a WhatsApp reminder agent on Twilio + Node + Claude API for a client about 4 months ago. The architecture was straightforward: user sends a WhatsApp message → Twilio webhook hits our endpoint → Claude parses intent and extracts time → MongoDB stores reminder → cron sends out the reminder when due.
Worked fine in dev. Worked fine in staging. Shipped it.
Three weeks in, users started complaining about getting duplicate reminders. Sometimes 2, sometimes 3 copies of the same message. Logs looked clean the cron only fired once per reminder.
The actual bug:
Our webhook endpoint took anywhere from 8-15 seconds to respond because the Claude call was inline (extract intent + parse date + generate confirmation, all sequential). Twilio's webhook retry policy kicks in if your endpoint doesnt respond in time they retry up to 3 times with backoff.
So when our endpoint was slow, Twilio would deliver the SAME inbound message 2-3 times before we could acknowledge the first one. Our agent would parse it 2-3 times, create 2-3 reminders, schedule 2-3 sends.
The duplicates only showed up on specific carrier+region combinations that we werent monitoring closely. Indian carriers seemed to trigger retries more aggressively than US carriers in our data.
The fix:
Idempotency at the webhook edge. Twilio sends a unique MessageSid with every webhook. We added a Redis-backed deduplication check that runs BEFORE any other processing:
if MessageSid exists in Redis (TTL 5 min):
return 200 OK immediately, skip processing
else:
set MessageSid in Redis with 5-min TTL
process the message
return 200 OK
Once that was in place, duplicate reminders went to zero. As a bonus, our Claude API spend dropped about 12% because we were no longer making redundant inference calls on duplicate webhooks.
Things we should have done day 1:
Edge case worth flagging:
Twilio retries on 5xx responses AND on timeouts. If your endpoint returns 200 OK but processing fails downstream silently, Twilio thinks you handled it. Make sure your idempotency check happens BEFORE you commit to the 200 OK otherwise youll have phantom-success records that arent actually processed.
Anyone else running Twilio webhooks with slow downstream processing (LLM calls, database writes, external API calls)? Curious what patterns others have used for handling the retry behavior. Are you using Twilio's request validation + idempotency, or building your own dedup layer?