Mautic SMS with Twilio: what the integration does
Marketing teams that already run Mautic campaigns for email often reach a point where text messages need to sit inside the same journeys. This section explains what the Twilio integration adds to that setup and what you should decide before you enable it. Twilio is the first and default SMS service Mautic implements, so it is the path most teams will evaluate first. You configure it by activating the Twilio plugin in Mautic and entering your Twilio account SID and auth token. Those two credentials connect your Mautic instance to your Twilio account, and the rest of this page builds on that connection.
The SMS channel does not sit outside Mautic's marketing model. Text message steps run inside the same campaigns as email and other channels, and they draw on the same contact records, segments and campaign logic. That has practical consequences. A contact can only receive a text if the record holds a usable mobile number, so your contact import and field design need to capture it. Your segments decide who enters an SMS branch, and your campaign flow decides when that happens. Before you build, map which messages move to text, which stay with email, and which contacts have agreed to receive texts at all. Confirm with your consent owner how that agreement is recorded on the contact record.
The Twilio setup has several pieces that teams should understand before they test. Mautic's Twilio configuration creates a Twilio Messaging Service that uses your phone number as a sender, and it has Send a Webhook selected under the integration settings. Check that the Messaging Service, the number and the webhook are the ones you intend to keep, because changing them later affects every campaign that sends texts. The Mautic documentation also sets out requirements for alphanumeric sender IDs. Read those requirements against the countries you plan to message, and confirm them against Twilio's current rules for each one before you choose a sender name.
Frequency rules decide how often a contact can be messaged on each channel, and a text message arrives on a phone where the contact sees it at once. Mautic lets you set frequency rules globally for the email and SMS channels, then override them for individual contacts. Decide your global limits before the first SMS campaign goes live, and record who is allowed to change per-contact overrides. This page covers the supported plugin method only. If your team considers another route for sending texts, treat that as a separate scoping decision and check it against the Mautic documentation for your release.
What you need before connecting Twilio to Mautic
Connecting Twilio to Mautic depends on three parts working together: a self-hosted Mautic instance that runs on a supported release line, a Twilio account that can send text messages from a number you own, and an administrator who can enter the plugin credentials. Check each of these before you change any settings, because a gap in one area usually shows up later as failed sends or campaigns that never trigger.
Self-hosted Mautic on a supported release
The Twilio plugin runs inside your own Mautic installation, so you need a self-hosted instance on a release line that still receives support. Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5, MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher, and Apache, Nginx or IIS as the web server. Confirm your PHP and database versions against the requirements page for the release you run, since the support dates differ across release lines.
Hosting that is not shared hosting
The Mautic project states that it should not be installed on shared hosting and recommends a VPS or dedicated server. Campaigns, segment updates and message queues place sustained load on the application and database, and shared plans often limit the PHP settings and background processes Mautic needs. Confirm with your hosting provider that you can run the required PHP version, a scheduler and long-running processes before you plan the SMS rollout.
Cron jobs running for campaigns
Mautic does not send campaign messages on its own schedule. It relies on cron jobs to update segments, update campaigns and trigger campaign actions, and the documentation says these jobs should be staggered. If cron is not running, an SMS step in a campaign will never fire, even though the plugin is configured correctly. Confirm that cron runs as the web server user with the correct PHP binary and that you can see its output in logs.
Twilio account SID and auth token
The Twilio plugin asks for your account SID and auth token, which authenticate Mautic to the Twilio API. Treat the auth token as a secret: store it only in the plugin settings, restrict who can view it in Mautic, and plan how you will rotate it if an administrator leaves. Confirm with Twilio that the account type you use permits the messaging you plan to send and that you can create the credentials Mautic needs.
Purchased Twilio phone number
Mautic's Twilio setup creates a Messaging Service that uses your phone number as a sender, so the number must exist in your Twilio account before you connect Mautic. Number eligibility for SMS varies by country and number type, and some destinations require registration before messages are delivered. Confirm with Twilio which number types you can use for your recipient countries and what registration steps apply. If you plan to use an alphanumeric sender ID instead, confirm its requirements in the Mautic Twilio documentation.
Mautic administrator access to plugin settings
Activating the Twilio plugin and entering credentials requires an administrator role in Mautic, and the same role controls the SMS channel, frequency rules and integration settings. Decide before the rollout who owns the Twilio credentials, who can edit campaigns that send texts, and who approves changes to sender settings. Confirm that the account you use has the permissions for plugin configuration and that someone else can take over these settings if needed.
How the Twilio plugin builds the sending path
The sending path begins when a campaign action asks Mautic to send a text message. The Twilio plugin, once activated, holds the Twilio account SID and auth token and uses them to authenticate every API request Mautic makes to Twilio. These credentials decide which Twilio account is billed, which numbers and services Mautic can see, and whose logs record the traffic. Before installation, decide which Twilio account or subaccount will own SMS traffic, who holds the auth token, and how the token will be rotated when staff change. Those decisions are easier to make now than to reverse after campaigns are live.
Mautic's setup creates a Twilio Messaging Service and adds the phone number as a sender. The Messaging Service is the Twilio object that groups senders and routes outbound messages, so Mautic sends through the service and the number is one of the senders it uses. The service is where Twilio-side settings such as sender pools and message handling are applied, while Mautic decides which contact receives which message and when. After setup, check in the Twilio console that the service exists, that the intended number is attached to it, and that the number supports SMS to every destination country your campaigns target. Confirm the exact labels and steps against the Twilio plugin documentation for the Mautic release you run.
The Send a Webhook option under integration settings tells Twilio to post message status events back to Mautic. Without it, Mautic knows only that Twilio accepted a message, and it cannot record delivery or failure on the contact timeline. Twilio must be able to reach the callback address over HTTPS, so the web server, firewall rules, reverse proxy and the configured base URL all have to agree. A mismatch in any one of them produces silent status loss, where messages are sent but outcomes never appear in reports. Confirm the exact option name and where the callback address is set in the release you run, then verify with a test message to a controlled phone.
Responsibility is split across three places: the plugin authenticates and sends, the Messaging Service selects the sender and handles carrier-facing settings, and the webhook returns outcomes to Mautic. When a message fails, the first question is which of these three stages stopped. Ask the implementation partner to document each setting, its owner and where its value is stored, and to include a test plan covering a successful send, a failed send and a status update. Keep a record of the account SID, service identifier and callback address in your configuration documentation so that a future upgrade or staff change does not require someone to rediscover them.
Configuring Mautic SMS with Twilio in order
This sequence connects a self-hosted Mautic instance to a Twilio account so campaigns can send text messages from a chosen sender number. It ends with a Messaging Service that holds the sender and a status webhook that returns delivery results to Mautic.
Activate the Twilio plugin in Mautic
A Mautic administrator opens the plugin management area and enables the Twilio plugin, which is the first step for SMS in Mautic. Confirm the exact menu labels in the Mautic Twilio documentation for your installed release, because they can differ between versions. Done correctly, the Twilio plugin shows as enabled in the plugin list, and its configuration fields become available for the account credentials in the next step. If the plugin does not appear, check that the plugin files are present on the server and that the cache has been cleared before you retry.
Enter the account SID and auth token
The administrator copies the account SID and auth token from the Twilio console and pastes them into the matching fields in the Mautic Twilio plugin settings. Use the production account, not a test or subaccount, unless the project specifically calls for one. Treat the auth token as a secret: limit who can view the Mautic configuration and record where the token is stored. The step is complete when the settings save without a validation error and the token field no longer displays in plain text.
Confirm the Twilio connection
Run the connection check that Mautic provides for the Twilio credentials, or save the configuration and confirm that the plugin reports a successful connection. A failure usually means the SID and token come from different accounts, the token was rotated in Twilio, or the server cannot reach Twilio's API over outbound HTTPS. Correct the credentials and repeat the check until it passes. Record the account and the date of the successful check in your change log so later troubleshooting starts from a known state.
Select or purchase the sending phone number
The administrator chooses an existing SMS-capable number in the Twilio account or buys a new one, then selects it in Mautic as the sender. Purchase and monthly number charges are paid to Twilio, so ask your Twilio account contact for current pricing for the countries you will message. If you plan to use an alphanumeric sender ID instead of a number, confirm the country-specific registration and format rules in the Mautic Twilio documentation first. The step is done when the number appears as active in the Twilio console and is listed as the selected sender in Mautic.
Let Mautic create the Messaging Service
Once the number is selected, Mautic creates a Twilio Messaging Service in the account and adds the phone number as a sender. Avoid editing this service by hand in the Twilio console during the initial setup, since later Mautic saves may overwrite changes. Check the Messaging Services list in the Twilio console and open the new service. The step is complete when the service exists and shows the chosen number under its senders.
Select Send a Webhook in integration settings
In the Twilio integration settings within Mautic, the administrator selects the Send a Webhook option so Twilio posts message status events back to Mautic. Confirm the option label against the documentation for your release, since the surrounding settings can change between versions. Save the configuration and reopen it to make sure the selection persisted. The step is complete when the webhook setting is saved as enabled and the callback address shown in Mautic matches the public address of your instance.
Confirm the webhook URL is reachable from Twilio
The Mautic webhook address must be reachable from the public internet over HTTPS, so check the reverse proxy, TLS certificate and firewall rules that expose the instance. Test from a network outside your own, then send a test message and watch for the status callback in Mautic logs or the Twilio request log. Failed callbacks usually come from a certificate problem, a blocked path or a redirect that drops the request body. The step is complete when a status callback for the test message arrives and is recorded against the contact.
Send a test message to a controlled handset
Before any campaign goes live, the administrator sends a test SMS to a handset the project controls, using a contact record that belongs to the test team. Confirm the message arrives, shows the expected sender, and that its delivery status updates in Mautic. Then review the frequency rules for the SMS channel, which can be set globally and overridden per contact, so that test and production contacts are handled as intended. The sequence is complete when the controlled handset receives the message and the contact history shows the delivery status.
Mapping phone numbers, sender IDs and contact channels
This table maps each Mautic field or setting to its Twilio counterpart for SMS sending. Read it as a checklist before you enable the channel: the first column is what Mautic holds, the second is where Twilio uses it, and the third is what to verify in your own environment. The main takeaway is that phone number format and sender ID rules depend on the destination country, so check them before launch.
| Mautic field or setting | Twilio counterpart | What to confirm |
|---|---|---|
| Contact mobile number | Recipient of the Twilio text message | Use international format with country code; check against destination country rules |
| Twilio phone number or Messaging Service | Sender of the message | Mautic's setup creates a Messaging Service that uses the phone number as a sender |
| Alphanumeric sender ID | Sender name shown on the recipient's handset | Check the docs' alphanumeric requirements and destination country support first |
| Twilio account SID and auth token | Plugin credentials entered in the Twilio plugin settings | Store the auth token in your secrets process and plan how it will be rotated |
| SMS channel frequency rule | Limits how often a contact receives texts | Set a global SMS rule, then confirm any per-contact overrides for your segments |
| Send a Webhook integration setting | Status callbacks to the contact's delivery record | Confirm which delivery status updates Mautic writes to the contact record in your version |
How frequency rules apply to text messages
Mautic frequency rules can be set globally for the email and SMS channels and overridden per contact. The practical consequence is that a text message counts against the SMS channel rule, and the email rule does not govern it. A team that assumes one shared limit across both channels will be surprised when a contact receives texts after a run of emails, or the reverse. Before the first text campaign, open the frequency settings and confirm that the SMS channel has its own global limit. Then write down how the email and SMS limits interact in your planned campaigns, because each channel carries its own rule. Treat the global settings and per-contact overrides as the only two controls the platform gives you for this, and plan the rest of this section around them.
Set the global SMS limit before the first campaign goes live. Agree the maximum text frequency with marketing, legal or compliance, and the owner of the Twilio account, then record that decision in your change ticket so the number has a clear source. Ask the Mautic administrator to enter it in the global SMS channel setting, and check afterward that the value sits under the SMS channel and that email sends are unchanged. Messages already queued or scheduled before the limit exists may behave differently from later sends, so avoid launching a campaign into a live audience while the setting is still being changed. Confirm how queued sends are handled in the version you run, using the Mautic frequency rules documentation and your own test results, and do not assume the behavior from another version.
Use a per-contact override only when there is a documented reason for it. Typical reasons include a customer who asked for fewer texts, a contact in a pilot group that needs a lower volume, or an account where a service notice must not compete with marketing messages. Every override needs a named owner who can explain why it exists, and a review date on which someone decides whether it still applies. Without those two fields, overrides accumulate, the global rule stops describing what contacts actually receive, and the team cannot answer a complaint about message volume with confidence. Store the owner and review date in the contact record if your data model has fields for them, or in a shared register maintained by marketing operations. Decide which option fits your model before the first override is created.
Test the rule with a contact whose SMS limit is set low before any production audience is loaded. Choose a test contact, set a deliberately low SMS limit on that record, and enroll it in a short test campaign that would send more texts than the limit allows. Check the contact timeline in Mautic and the message log in your Twilio console to confirm that sends stop at the limit and that the test contact still receives emails within the email rule. Then repeat the check with a contact that has the global limit to confirm the override does not affect other records. Remove the test override afterward, confirm the record returns to the global setting, and keep the test result with the change ticket so the behavior can be reproduced after an upgrade.
Protecting Twilio credentials and the webhook endpoint
The Twilio plugin holds credentials that can send messages from your account, and its webhook can change contact records in Mautic, so these controls guard both. Each card ties one control to a specific risk: a leaked token sending messages, or a spoofed status callback altering contact history. Confirm the plugin behavior described in each card against the Mautic release you run before you rely on it.
Keep the auth token out of shared documents
The Twilio account SID and auth token are enough to send messages from your account, so a copy in a wiki page, ticket or chat thread is a leak. Enter them only in the Twilio plugin settings in Mautic, and keep your own copy in a secrets manager with a named owner. Before go-live, search onboarding notes, runbooks and shared drives for pasted credentials and remove any you find.
Limit who can view plugin settings
Anyone who can open the Twilio plugin configuration can read stored credentials or change sender settings. Review Mautic user roles and grant plugin administration only to the people who run SMS campaigns. Confirm whether your Mautic version masks credential fields after saving, and test that a campaign manager without admin rights cannot open the settings page.
Rotate the auth token after staff changes
When someone who knew the auth token leaves or changes role, treat the token as shared with them. Generate a new token in Twilio, update the Mautic plugin settings, and send a test message before retiring the old value. Tie a rotation review to every change in Mautic admin access, and record who performed each rotation and when.
Restrict the Twilio API key scope
If the plugin accepts a Twilio API key in place of the main account credentials, a key limited to the Mautic workload reduces what a leaked value can do. Confirm with the plugin documentation for your release whether API key authentication is supported. If it is, create a key for this integration only and document which account or Messaging Service it can reach.
Serve the webhook endpoint over HTTPS
Twilio sends delivery status callbacks to the webhook URL that Mautic exposes. Over plain HTTP, anyone who can observe or inject traffic can spoof a callback and mark contacts as delivered, failed or opted out. Serve the endpoint with a valid certificate, redirect HTTP to HTTPS, and confirm the URL configured in Twilio starts with https. Also confirm whether your release validates Twilio request signatures.
Log access to the Mautic admin area
Changes to plugin settings, user roles and campaigns are the events you need to reconstruct after a suspicious SMS send. Confirm which admin actions Mautic records in its logs and whether those logs leave the web server. Forward authentication and configuration events to a central log store with retention set by your security policy, and review them after each staff change.
Common SMS failures in Mautic with Twilio and their causes
This table lists six SMS failures that can appear when Mautic sends texts through Twilio, with the likely cause and fix for each. Match the symptom in the first column, then work through the checks in the last column with your Twilio console open. Most failures sit in one of three places: the credentials, the Messaging Service, or the server running Mautic's cron jobs.
| Failure | Likely cause | Fix and checks to confirm with Twilio |
|---|---|---|
| Credentials rejected | Account SID or auth token entered incorrectly, or taken from a different Twilio account. | Re-enter the SID and auth token in the Twilio plugin settings. In Twilio, confirm the credentials belong to the account that owns the Messaging Service. |
| No sender available in the Messaging Service | The Messaging Service has no active sender, or the phone number was removed from its sender pool. | Add an active sender to the Messaging Service in Twilio. Confirm the Mautic integration points to that same service. |
| Alphanumeric sender ID rejected for a country | The destination country restricts alphanumeric sender IDs or requires registration before use. | Check Twilio's country rules for the destination. Confirm the sender ID is permitted there, or send from a phone number sender for that country. |
| Delivery statuses not updating | The webhook URL set under Send a Webhook is unreachable from Twilio, often because of a firewall, DNS issue or private address. | Confirm the webhook is enabled and the URL is public over HTTPS. Check Twilio's message and webhook error logs for failed callbacks. |
| Messages not sending from campaigns | Cron jobs that process campaign triggers are not running, or are not staggered, so SMS actions never execute. | Confirm the campaign cron job runs on schedule on the Mautic server. Review the cron output after each run. Twilio shows no messages until the job fires. |
| Contacts receiving fewer texts than expected | A global or per-contact SMS frequency rule suppresses sends after the limit is reached. | Review the global SMS frequency rule and any per-contact overrides in Mautic. Suppressed contacts never reach Twilio, so check their contact history in Mautic first. |
Testing SMS sends before a campaign goes live
Run a scripted test sequence before any SMS campaign goes live, and record each step as a pass or fail check. Use a controlled contact list built from handsets the team owns, and include at least one test contact whose SMS preference is set to opted out. The goal is to show that the Twilio plugin, the Messaging Service and Mautic's frequency and consent logic behave as configured before a real segment receives a message. Confirm each result in two places: the Mautic interface and the Twilio message log, with the handset as the final check.
Start with a test campaign that contains one SMS action, targeted only at the test contact list. Send it, then compare the message content with the approved text, including any token substitutions that resolve for each test contact. Check the sender identity on the handset. Depending on your setup, it will show either a phone number from the Messaging Service or the alphanumeric sender ID you configured, so match it against the sender you intended. Next, open the delivery status in Twilio and in Mautic and confirm they agree. Finally, open the contact timeline in Mautic and confirm the SMS send is recorded against the correct contact and campaign.
Next, test the frequency rule. Mautic allows frequency rules to be set globally for the email and SMS channels and overridden for an individual contact, so test both paths. Send one message to a test contact, then trigger the campaign a second time within the limit you configured. The second send should be blocked for that contact on the SMS channel. Repeat the test with a contact that carries a per-contact override and confirm that it follows the override while the global setting still applies to the other test contacts. Check the exact rule labels and defaults in the release you run, since they can change between versions.
Then confirm that an opted-out contact is excluded from sends. Opt a test contact out through the SMS preference on the contact record, or by sending the opt-out keyword that your Twilio Messaging Service handles, and check that the opt-out appears on the contact timeline. Trigger the campaign and confirm there is no outbound message in the Twilio log and nothing arrives on the handset. Ask the person who owns the Twilio configuration which opt-out keywords the Messaging Service handles by default, and whether Mautic receives that event. A keyword handled only on Twilio's side will leave the Mautic record unchanged, so this link needs its own test.
Run the entire sequence in a staging Mautic with a separate Twilio account or test credentials wherever possible. This reduces the risk of messaging real customers during testing and keeps test traffic out of production reports and billing. Confirm that the staging instance has its own Messaging Service and webhook configuration, so Twilio status callbacks reach the staging site, and only the staging site. Keep a test log with dates, test contact identifiers, screenshots of handset messages and the Twilio message identifiers. Repeat the full sequence after any change to the plugin, the Messaging Service or the frequency settings, and ask your implementation partner to include it in the acceptance criteria.
Questions buyers ask about Mautic SMS with Twilio
How much does Mautic SMS with Twilio cost to set up?
The cost has two parts. One-time work is DeployOpen's implementation effort: configuring the Twilio plugin, the Messaging Service, webhooks and frequency rules, building the test campaigns, and testing. This is quoted from a written scope. Recurring charges are the Twilio message and phone number fees. Twilio sets those rates and bills your Twilio account, so DeployOpen does not set or resell them. Ask for a quote that lists the one-time items separately and states which party holds the Twilio account. Confirm current per-message and per-number pricing directly with Twilio, because it varies by destination country and message type. Also ask how changes to the scope after signing are priced.
How long does the Twilio integration take to configure and test?
The duration depends mainly on campaign complexity. A single plugin setup with one sending number and one simple campaign is far less work than several SMS campaigns with segment logic, opt-in and opt-out handling, and per-country sender rules. The main variables are the number of campaigns, the number of destination countries, how many sender options you need, and how thorough the test plan is. DeployOpen does not publish a fixed duration, so the timeline is agreed in the written scope. Ask for the timeline to show configuration, test rounds, and the point where your team signs off. Confirm sender ID and registration lead times with Twilio before the build starts, since those can hold up sending regardless of how quickly the configuration is done.
What does the client need to provide for the Twilio work?
Your team needs to provide four things. First, access to the Twilio account so the account SID and auth token can be entered into Mautic, with secrets stored under your own handling rules. Second, a phone number or sender setup in Twilio, along with a Messaging Service if you want Mautic to use one. Third, a test list of phone numbers owned by people who agree to receive test messages. Fourth, a named owner who makes decisions on consent, opt-out wording, and text message frequency. You also need administrator access to the Mautic instance and the ability to make the Twilio webhook reachable from the internet. Without these inputs, the work stops at the first decision point, so confirm them before signing.
Can an internal team set up Mautic SMS with Twilio alone?
An internal team can do it alone if it has three skills in place: Mautic administration, Twilio account administration, and time to run a full test cycle. The plugin configuration itself is a small part of the work. The harder parts are making sure Twilio can send delivery status callbacks to your Mautic instance, setting up the cron jobs that drive campaign triggers, configuring frequency rules for the SMS channel, and documenting how consent is recorded. Many teams hire a partner when they lack one of these skills, when they want a written test record for an internal or external review, or when they need the work finished alongside other Mautic changes. Ask your own team to list who will own each task before deciding.
Who decides consent and text message frequency limits in Mautic?
Your organization decides. Mautic lets you set frequency rules globally for the email and SMS channels and override them for individual contacts. DeployOpen configures those settings as your owner specifies, but the choice of limits, the consent basis for each list, and the opt-out wording are business and legal decisions. Name one owner who signs off on these decisions in writing before campaigns are built. Ask your legal or compliance lead to review the consent flow and the message content, because SMS rules differ by country and by message type. Keep the approved settings in the handover documentation so that later campaign changes can be checked against them.
What should a quote for Mautic SMS with Twilio include?
A useful quote lists the scope in specific terms. It should name the Mautic version and hosting assumptions, the plugin configuration steps, the Messaging Service and sender decisions, the webhook setup, the frequency rule configuration, and the number of campaigns or sequences to build. It should describe the test plan, including which test numbers and destination countries are covered, and what handover documents you receive. It should state the assumptions your team must meet, such as access and test numbers, and the process for changes to scope. Finally, it should say what is excluded. Twilio message and number charges, carrier or sender registration fees set by Twilio, and any ongoing support are separate items and should appear as separate lines.
What goes wrong with Twilio sender IDs in Mautic?
The most common problem is choosing a sender type that the destination country or Twilio account does not accept. Mautic's Twilio setup uses a Messaging Service with a phone number as the sender, and the Mautic documentation covers alphanumeric sender ID requirements. Before you build campaigns, confirm with Twilio which sender types each destination country supports, whether any sender registration is required, and how long that takes. Messages that fail for sender reasons often look like a Mautic problem at first, so check the Twilio delivery logs and the Mautic message status for each test send. Record the approved sender setup in the handover documentation so that future campaigns use the same configuration.
How DeployOpen scopes and delivers Mautic SMS integrations
DeployOpen plans and implements Mautic SMS with Twilio inside infrastructure you control, starting from a written scope that names the Twilio account, sender configuration and campaign rules before any build begins. Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing first, and a quote follows from that scope.
How we scope
- Confirm the Mautic release line and hosting environment that the Twilio plugin will run on.
- Record the Twilio account SID, where the auth token will be stored, and who holds Twilio console access.
- Agree the sender ID approach with Twilio and Mautic's alphanumeric sender ID requirements before campaigns are designed.
How we build
- Activate the Twilio plugin and enter the account SID and auth token into Mautic's configuration.
- Set up the Twilio Messaging Service with the phone number as sender and the Send a Webhook setting Mautic expects.
- Configure global SMS frequency rules, then test per-contact overrides against sample segments before campaigns go live.
How we hand over
- Provide a written runbook covering Twilio credential rotation, webhook endpoints and sender configuration.
- Deliver test evidence from sample SMS campaigns, showing sends, status callbacks and frequency rule suppression.
- Run a handover session with the team that will own SMS campaigns, segments and channel settings.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Recheck SMS campaign triggers after each Mautic upgrade, since campaigns depend on the staggered cron jobs the docs describe.
- Review Twilio account changes, such as sender or number updates, with your team before they reach production.
