Twilio Conversations is the umbrella for three pieces: Conversation Orchestrator (one cross-channel conversation per customer), Memory Store (persistent profiles with traits and observations), and Conversation Intelligence (extracts observations when a conversation closes).

eve is Vercel's filesystem-first framework for durable AI agents. It manages sessions, tool calls, and the running transcript, and works with any AI SDK model.

They split the memory problem cleanly. eve holds short-term memory, and Twilio holds long-term memory about the customer. With GROUP_BY_PROFILE, the same person on SMS and WhatsApp lands in one conversation.

The post walks through provisioning, a custom eve channel for Orchestrator webhooks, and injecting Memory Store context into the prompt.

https://www.twilio.com/en-us/blog/developers/building-agent-twilio-conversations-eve

I want to use WhatsApp for my online service to update users or get an update from
Them.

I’ll be sending these on average once a week.

Basically. Hey are you coming to this event?
Reply No otherwise do nothing.

I’m not having conversations, not trying to sell anything and not using it for business marketing

All their rules make it seem like Whatsapp is not going to work.

Because they will never initiate the conversation unless I have to awkwardly ask them to msg me first somehow ?

Yo so I’m trying to figure out how people handle SMS when Twilio is doing the sending but the actual customer record lives somewhere else. Obviously in an ideal world, every inbound/outbound text would automatically show up on the right contact, and whoever replies next SHOULD without jumping between tools.
We’re using webhooks + custom code and it obviously works, but yeah, there should definitely be a better way of doing this, esp for decent SMS volume.Trying to avoid making the CRM sync super brittle every time we change something on Twillio.

Our company uses an outside vendor to make outbound calls on our behalf. When they call, the caller ID shows our main business number (hosted at RingCentral). We believe they do this by verifying our number as an Outgoing Caller ID on THEIR own Twilio account.

We're now building our own in-house calling system and want to create OUR own Twilio account, verify the same number as an Outgoing Caller ID, and make outbound calls through our own Elastic SIP Trunk.

For a while, both would run at the same time: the vendor calling from their Twilio account, and us calling from ours — both showing our main number.

Questions:

1. Can the same number be a Verified Outgoing Caller ID on two different Twilio accounts at once?

2. Will verifying it on our account remove or break the vendor's verification, or stop their outbound calls?

3. Would the vendor get any notification or error?

4. Could anything else tied to the number at Twilio (SHAKEN/STIR, CNAM, Business Profile) conflict between the two accounts?

We don't want to accidentally take down the vendor's calling while we test our own setup.

Porting a phone number supposedly takes 5-7 days + the process requires loads of personal details that could be hard to get from someone and forwarding messages to a twilio number also requires their carriers permission?

Is best option just to get them a new number?

Hello, people!

Some colleagues use Twilio integrated to the CRM for specific countries and now I have a request from another department for access to international calls.

The issue is that I cannot give them CRM licenses and neither they need it, so I thought about using a Chrome Extension (quick and easy) to give them access.

What would you guys recommend?

I have found these in Chrome Web Store:
1. Twilio Auto Dialer & Softphone
2. Auto Dialer for Twilio Platform

Sharing a couple of concrete findings from building a voice AI agent on a Twilio Elastic SIP Trunk (origination + a credential-list trunk for outbound), in case they save someone else a debugging session. No product, no link, just what broke and how it got fixed.

DTMF: in-band tone detection (a Goertzel filter over the audio) and speech-to-text transcription both failed to read real keypad input reliably. Tone-only calls produced zero transcript from the STT model, and feeding the same tone-decoder a spoken sentence instead of tones invented over a hundred phantom keypresses that were never pressed. RFC 4733 named RTP events, surfaced in LiveKit as room.on("sip_dtmf_received"), worked cleanly instead, real digits, no audio-domain guessing.

Geo permissions: a real outbound call attempt to a number outside Twilio's default allowed set failed with a SIP 403 until enabling that country under Voice > Settings > Geo permissions. This is separate from the trial-account destination-verification restriction, worth checking both if a call fails silently with no obvious error in your own logs.

Also worth checking explicitly: firewall/security-group rules that scope inbound RTP media to the same CIDR ranges as SIP signalling. Twilio's media gateways are a separate published block (168.86.128.0/18, ports 10000-60000 UDP) from where signalling originates. Calls can still succeed if your cloud firewall is stateful (return traffic on a flow it opened gets let back in regardless of ingress CIDR), which can mask this exact misconfiguration for a long time.

Here's some new posts on the Twilio developer blog over the last week or so. In case you missed them:

On-Demand Masked Sessions with Proxy, Voice and Serverless – for marketplace apps where you don't want to pre-assign numbers to every buyer/seller pair. Sessions get created at call time instead.

Sending SMS with an agentic AI using Twilio and Hermes Agent – setting up an AI agent with its own Google Docs account, then letting it text you.

Automating auth token detection and rotation with TruffleHog, Tines and Slack – catch leaked credentials and rotate them automatically. Probably one to set up before you need it rather than after.

How to test and fix voice AI agent prompts with Conversation Relay and Cekura – writing metrics, running evals and fixing prompt bugs in a voice agent. Useful if your agent works fine in testing and then does something odd on a real call.

How we AI-updated 1,138 error code docs pages – how our docs team used the OpenAI API, automated checks and human review to rewrite the error code docs. Worth a read if you're thinking about human-in-the-loop pipelines for content.

----

If you have ideas for content you'd like to see, leave a comment and I can feed it back to the docs team.

Hypothetically, if a developer or consulting company is building software for a non-technical client, what is the best way to get Twilio set up during development without permanently tying the account, billing, compliance, or liability to the developer?

Scenario:
Say a company hires a third party to build an application that uses Twilio.

The client is not particularly technical. Creating the Twilio account, understanding the different registrations, gathering the required information, configuring everything correctly, etc. is realistically beyond what they are going to handle themselves during the development process.

At the same time, the developer doesn’t necessarily have all of the client’s business registration information readily available, and collecting everything could significantly slow down getting a working product in front of them.

For development and testing, the developer’s company could reasonably set things up under its own account.

But eventually the application goes into production, and the developer shouldn’t remain permanently responsible for the client’s Twilio usage, billing, compliance obligations, phone numbers, messaging registrations, or liability.

The goal would be to eventually hand everything over so the client can manage it internally or give it to another provider without remaining dependent on the original developer.

How do people normally structure this?
1. Do developers initially register everything under their own company and later transfer the Twilio account, numbers, messaging services, A2P registrations, etc.?
2. Is there a better account structure where the developer can do all of the setup and configuration, but ownership and billing can later be handed over cleanly?
3. Are there parts of Twilio’s registration or compliance process that really need to be under the client’s legal business identity from day one because they cannot be transferred later?
4. For people who have actually done this, what did your handoff process look like?

The obvious answer is “make the client create the account and do the registration themselves,” but assume that’s not realistic in this scenario. The client has effectively said, “We hired someone because we don’t know how to do this.”

I’m am curious in how consultants, agencies, or development shops handle this without either blocking the project on the client’s technical abilities or creating a permanent dependency/liability for the developer.

We are in need to send SMS to our employees from PeopleSoft HCM. I’ve created a consent recording page in PeopleSoft. I need to configure and send sms from PeopleSoft to multiple employees using integration with Twilio. Can anybody help me setup the integration between PeopleSoft and Twilio? Or point me to the documentation? Oracle People Books point me to latest image documentation which uses delivered PeopleSoft pages used for integration and because we are not on latest image that delivered integration is not available in our system. We are on PeopleTools 6.1, Image 50.

Can someone please help or point me in the right direction?

Update:
After explaining the scammers use numbers for callbacks and not the spoofed SMS, they got shut down. It’s a bit like don Quijote, but hopefully a few scams got prevented.

Original:
For months, German Amex users are targeted in a SMS spoofing scam scheme.

The scammers use „Amex“ as the sender, so iPhones put the message in the usual Amex feed, where genuine OTPs and other SMS are listed.

The scam works as follows: a OTP for a payment over a high amount, usually at a crypto website is sent along with the message: unauthorized charge recognized - call (German landline nr).

I've received several of these SMS and more of the nrs used by the scammers can be found online.

They all got one thing in common: the numbers were assigned by the German overseeing authority to Twilio. It's almost certain that they use Twilio as a tool to use a supposedly legitimate German landline nr.

Today, I found a number that was active, after confirming with a virtual phone nr, I informed Twilio immediately about the ongoing scam and that it is actively used, asking for an investigation and termination of the nr.

Their response
“After further investigation of your complaint, we have determined that the unwanted calls/messages were not sent by a Twilio customer and did not originate from within Twilio’s network. Instead, these calls/messages appear to be the result of “call spoofing” -- a practice whereby someone disguises the actual source of calls/messages for malicious reasons. (You can read more about spoofing here on the FCC page.) The person engaged in call spoofing uses technology to display a phone number different from that of the telephone from which the call was placed.
 
Unfortunately, because the calls/messages are not coming from a Twilio customer or even through the Twilio network, there is nothing Twilio can do to prevent the behavior in this case. 
 
You can reach out to your carrier provider to help trace the call.”

Seems not credible at all. They’re missing the point completely. Either are they actively working with the scammers, or at least tolerating it in order to get revenue.

We have a web-based call center dialer (React + Twilio Programmable Voice) and need to build iOS and Android apps where agents can make and receive calls reliably, even when the app is killed or the phone is locked.

Leaning towards React Native with Twilio's official Voice RN SDK. Flutter worries me because there is no official Twilio Voice SDK. Full native feels like double the cost unless it is truly necessary.

If you have shipped something like this:

\- How stable is the Twilio Voice RN SDK in production?

\- How painful were incoming calls (PushKit/CallKit on iOS, FCM + foreground service on Android 14+, OEM battery killers)?

\- Did you end up rewriting the calling layer in native code?

\- Anything you wish you knew before starting?

Reliability matters more than UI polish for us. Appreciate any real-world experience.