Use Case — OTP & 2FA Delivery

Use Case — OTP & 2FA Delivery

One-time passwords (OTP) and two-factor authentication (2FA) codes are the highest-urgency SMS traffic in any organization. A login code that arrives 30 seconds late is functionally useless — users abandon the flow, support tickets spike, and conversion drops. Message Center's trigger mode is purpose-built for exactly this scenario.

The Challenge

OTP and 2FA delivery differs fundamentally from bulk campaign delivery:

• Unpredictable volume — authentication events happen in real time, not on a schedule
• Zero latency tolerance — a 5-second delay is acceptable; 30 seconds is not
• One number at a time — each send is a single recipient, not a batch
• Personalized content — each message contains a unique code, not a shared template
• Regulatory scrutiny — sender identifiers for OTP traffic must be pre-approved in many markets

Bulk campaign tools with file-upload workflows are a poor fit. You need an API you can call from your application backend the moment an authentication event fires.

How Message Center Handles It

Trigger Mode Campaigns

In trigger mode, a campaign is created with no recipients and no file upload. Once approved, it accepts phone numbers one at a time via API — each number triggers an immediate send.

Setup flow:

1. An admin creates a trigger-mode campaign with the approved sender name and message template
2. A moderator approves the campaign (one-time; the campaign stays active indefinitely)
3. Your application backend calls POST /jobs/{sqid}/numbers with a single phone number and personalized message text each time a user needs a code
4. The SMS Core dispatches the message immediately — no scheduling, no queue delay

Why this matters for OTP:

• The campaign approval happens once, not per-send — no moderation latency on individual messages
• The trigger endpoint is a simple REST call from your application — no file prep, no wizard
• The approved sender name is locked at campaign creation — no risk of sending OTP traffic from an unapproved SADDR

Sender Name Approval

Carrier registration requirements for sender names are strict in most markets. A sender named YourBank submitting OTP traffic must be pre-registered with the carrier. Message Center enforces this: every campaign must specify an approved sender name revision. You cannot accidentally send from an unapproved SADDR.

The revision approval workflow creates an immutable record of which SADDR was approved by which moderator and when — directly relevant for carrier audit requests.

Architecture Pattern

User attempts login
        │
        ▼
Your authentication service
        │  POST /jobs/{sqid}/numbers
        │  { number: "998901234567", message_text: "Your code: 7482" }
        ▼
Message Center BFF
        │  mTLS
        ▼
SMS Gateway Core ──▶ SMPP Proxy ──▶ Carrier

The application backend calls the Message Center API directly. No human is in the loop after the initial campaign approval.

Operational Considerations

Rate limiting: Message Center enforces per-workspace rate limits. For high-volume OTP (e.g. a bank with hundreds of logins per second), configure CORE_AGENT_CONNECTIONS to match the expected concurrency and work with the SMS Core capacity planning guide.

Delivery confirmation: Trigger mode campaigns track per-recipient delivery status. Your backend can poll GET /api/campaigns/{externalId}/recipients to verify delivery — useful for fallback flows (e.g. "SMS not received? Try again").

Workspace isolation: Run OTP traffic in a dedicated workspace. This separates OTP delivery reports, audit logs, and sender names from marketing or bulk notification traffic — cleaner operations and cleaner compliance audit trails.

Multiple applications: Each application (login service, password reset, transaction confirmation) can have its own trigger campaign in the same workspace, each with its own approved sender and audit trail. No cross-contamination between flows.

Compliance Benefits

• Every OTP send generates an audit record: which campaign, which user triggered the send, timestamp, sender name revision used
• The moderation gate ensures OTP campaigns have been reviewed and approved by an authorized person before any live traffic
• Sender name revision history provides carrier audit evidence without manual record-keeping

Summary

Next Steps

• Core Concepts — trigger mode explained in the campaign modes table
• Creating a Campaign — wizard walkthrough including trigger mode setup
• Senders and Revisions — sender name approval workflow