Odoo and Twilio for SMS and Voice

What ships, verified

Two separate things, and conflating them is the usual starting error.

Native SMS. Odoo has an SMS framework in Community. It sends through Odoo's own in-app purchase service, with credits purchased from Odoo, and it is wired into mailings, automated actions and record-level sending already.

sms_twilio, present in the Odoo 19 Community addons. Despite the name, its role is Twilio account configuration oriented at voice calling from within Odoo rather than replacing the SMS pipeline.

So the honest framing is that Odoo already sends SMS, and Twilio is an alternative route you might have reasons to prefer.

Reasons to prefer Twilio

Four that hold up, and a lot of projects that start without any of them.

Volume pricing. At scale, per-message cost differences become material, and Twilio's pricing is transparent and negotiable in a way credit bundles are not.

Coverage. Delivery quality varies by country and by route. If your market is poorly served, controlling the route matters more than convenience.

An existing number. A business already using a number for customer contact usually cannot move it into a bundled service.

Regulatory or contractual control. Some sectors need to know and evidence how messages were delivered.

If none of those apply, the native service is fewer moving parts, already integrated, and does not need building.

Voice

This is where Twilio adds something Odoo does not have natively: clicking a phone number in Odoo to place a call, with the call logged against the record.

For a sales or support team making calls all day, that is a real saving, both in dialling time and in call activity actually being recorded rather than remembered.

Two things to plan for. Call quality depends on the network and the browser, not on Odoo, so a poor experience is usually not an Odoo problem and will be reported as one. And recording is a legal question before it is a technical one: consent requirements vary by jurisdiction, and enabling it because it is a checkbox is how a business acquires a compliance problem.

Building your own SMS route

If you need Twilio for messaging specifically, the shape is straightforward and the details are where it goes wrong.

Send asynchronously. Not in the user's save. A slow API call should never block someone's work or roll back their record.

Handle delivery status. Twilio reports delivery through webhooks, and if nothing consumes them you know only that you handed the message over, not that it arrived. For anything transactional, undelivered and delivered are very different states.

Store the message id. It is what makes the send idempotent, so a retry updates rather than duplicating, and it is what lets you investigate a specific message later.

Normalise numbers. Phone data is messy: local formats, missing country codes, spaces and dashes. Store in a consistent international format and validate before sending, because failures here are per-record and silent.

Consent, quiet hours and cost

Three operational points that outlast the build.

Consent is not optional in most jurisdictions, and unsubscribes must work. Model consent as a field on the partner and check it at send time rather than trusting the list that was uploaded.

Time zones matter. A message that is fine at 10am is a complaint at 3am, and a scheduled send computed in server time will do exactly that to somebody.

Every message costs money. An automation looping on a write can send hundreds before anyone notices, and unlike email there is a per-message bill. Rate limit anything automated, and cap it, which is a specific case of the failures in integration mistakes.

The WhatsApp question

Businesses evaluating SMS often want WhatsApp instead, and it is a different system with different rules, covered in Odoo and the WhatsApp Business API. Notably, Odoo's own WhatsApp module is Enterprise only, whereas the SMS framework is not.