Sending transactional SMS and email from your application

Transactional messages are triggered by something a customer did or something that happened in your system: an order placed, a payment received, an appointment tomorrow. They should be automatic, fast and consistent.

Keep templates out of code

Store message templates with placeholders — `{name}`, `{amount}`, `{date}` — so the wording can change without a software release. Version them, and review changes like any other content.

Send through a provider API

Messaging providers expose HTTP APIs for SMS and email. Your application calls the API with the recipient, template and values; the provider handles routing to networks or mail servers and reports delivery back, often through a webhook.

Log every message

Record what was sent, to whom, when, the provider's message ID and the delivery status. When a customer says "I never got the code", you can answer in seconds.

Respect channel limits

• Keep one-time codes short-lived and never reuse them.
• Do not put sensitive details — full account numbers, medical information — in SMS.
• Throttle sends so a bug cannot message every customer at once.

Test with real devices

Check how messages look on common phones and email clients before go-live, including how links and special characters render.

See transactional notifications and API integration.