Skip to content

How can Mautic 7 send consent-aware SMS through AWS End User Messaging without n8n?

0

I am integrating Mautic 7 with AWS End User Messaging SMS through an open-source plugin.

The integration uses:

  • An EC2 instance profile instead of AWS access keys
  • AWS End User Messaging SMS
  • Mautic native SMS campaigns
  • E.164 phone normalization
  • Consent and approved-segment checks
  • Canary and production delivery modes
  • Daily and per-minute safeguards

What AWS best practices should I follow for CloudWatch or SNS event destinations, delivery status tracking, and throughput when sending SMS to an approved opt-in segment?

Repository: https://github.com/beto2l/mautic-aws-eum-sms

1 Answer
0

The production-readiness guide AWS published (June 2026) has a specific checklist for this, three pieces matter most for your setup.

Event destinations: you need a configuration set pointing to CloudWatch Logs, SNS, or Firehose (or a combination). CloudWatch Logs gives you 90-day retention with alarms on delivery failures and throttling, good for operational monitoring. SNS lets you push delivery events in real-time back to Mautic or another system if you need that. Firehose to S3 + Athena is for compliance audits where you need queryable history beyond 90 days. Without a configuration set, you only get basic EventBridge events that omit recipient details and carrier response context. The guide has the exact CLI commands for creating configuration sets and wiring up each event destination type.

Throughput: AWS measures this in Message Parts per Second (MPS), not messages per second, because long messages split into 140-byte parts. Default for short codes is 100 MPS, but you can request higher limits via a support case. The formula is (peak hourly volume / 3,600) × 2 to estimate what you need. Approval takes 1-3 business days. If you're on a toll-free number instead of a short code, that caps at 3 MPS, so the origination identity type you're using changes the answer here.

Opt-out lists: if you're sending both transactional (OTP, account notifications) and marketing SMS from the same Mautic instance, AWS best practice requires separate phone numbers and separate opt-out lists per use case. The default opt-out list blocks opted-out numbers from all SMS account-wide, which means someone opting out of marketing would also lose transactional messages. Separate pools fix that but cost more (extra phone number). If you're only doing one type, single pool works fine.

What's your expected send volume (daily total and peak MPS) and are you mixing transactional + marketing, or just one? Those two facts change which architecture makes sense.

I do AWS messaging and architecture advisory work, happy to put together a written production-readiness review with the specific CLI commands and IAM roles for your setup if that's useful.

answered 19 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.