CPaaS Integration: Adding Automated Calls and SMS to Legacy Systems

🔑 Key Takeaways:

  • CPaaS (Communications Platform as a Service) lets you add voice and SMS capabilities to existing software through REST APIs—without replacing legacy systems
  • The integration pattern that works for most legacy systems is a middleware layer: a lightweight service that receives events from the legacy system and calls the CPaaS API, keeping both sides decoupled
  • The hardest part of most CPaaS integrations isn't the API calls—it's normalizing phone number formats and handling opt-outs across systems that weren't designed to share data

Most organizations don't have the luxury of starting with a clean slate. The customer database is a 15-year-old CRM. The billing system runs on Oracle. The scheduling software was custom-built in 2008 and has never been replaced because too much depends on it. Adding automated calling and SMS to any of these systems doesn't mean ripping them out—it means connecting them to a CPaaS API that handles the communication infrastructure while the legacy system keeps doing what it does.

This is what CPaaS integration actually looks like in practice.

What CPaaS Provides (and What It Doesn't)

A CPaaS provider handles the telecommunications infrastructure: carrier connections, number provisioning, message delivery, call routing, delivery status reporting, and compliance infrastructure like STIR/SHAKEN attestation. What it doesn't provide is the business logic—who to call, when, with what message, and what to do with the response. That logic lives in your system.

CPaaS Handles Your System Handles
Carrier routing and delivery Contact selection and targeting
Phone number provisioning Consent management and opt-out records
Delivery status reporting Campaign scheduling and timing
Inbound call/SMS routing Response handling and business logic
STIR/SHAKEN attestation Message content and personalization

Three Integration Patterns for Legacy Systems

Pattern 1: Direct API Call from Legacy System

The legacy system makes HTTP calls to the CPaaS REST API directly. Works when: the legacy system can make outbound HTTP requests, the development team has access to modify the application, and call/SMS volume is low enough that synchronous API calls don't impact system performance.

Example trigger: When a record in the scheduling system changes status to "Appointment Confirmed," the system calls the CPaaS API to send an SMS confirmation to the patient's phone number.

Pattern 2: Middleware Integration Layer

A separate lightweight service sits between the legacy system and the CPaaS API. The legacy system writes events to a database table, message queue, or file—whatever it already knows how to do. The middleware service reads those events and calls the CPaaS API.

This pattern is preferred when you can't modify the legacy system's core application, when you need to add transformation logic (phone number normalization, opt-out checking, rate limiting) without touching legacy code, or when the same communication layer needs to serve multiple legacy systems.

Middleware Pattern: Basic Architecture
Legacy System → writes events to → Queue/DB Table
                ↓
Middleware Service (polls queue)
  - Normalizes phone numbers to E.164
  - Checks opt-out suppression list
  - Applies time zone calling rules
  - Calls CPaaS REST API
  - Writes delivery status back to legacy DB

Pattern 3: Database Trigger / ETL Export

For systems where application-level modification is impractical, a database-level trigger or scheduled ETL export can feed a communication queue. A nightly job exports contacts needing appointment reminders; a real-time trigger fires when payment status changes. This is the lowest-touch approach to legacy integration—you never touch the application code, only read the data it produces.

The Phone Number Normalization Problem

Legacy systems were often built before E.164 formatting was standard. A contact database might contain phone numbers in any of these formats—all representing the same number:

  • 2125550100
  • 212-555-0100
  • (212) 555-0100
  • +12125550100
  • 1-212-555-0100
  • 212.555.0100

CPaaS APIs expect E.164 format (+12125550100). Your integration must normalize all legacy formats before calling the API. A reliable normalization function strips all non-digit characters, checks length, and prepends +1 for 10-digit US numbers. Handle edge cases: extensions (drop them or store separately), international numbers that don't follow US format, and numbers that are clearly invalid (fewer than 10 digits).

Add Voice and SMS to Any System with a Clean API

Robotalker's REST API integrates with legacy systems, CRMs, and custom applications to deliver automated calls and SMS from your existing workflows.

  • ✔️ REST API with clear documentation
  • ✔️ Webhook delivery status callbacks
  • ✔️ Phone number validation and DNC tools
Start Free Trial →

FAQ: CPaaS Legacy Integration

Yes—most legacy systems without APIs still produce data in some accessible form: database tables, exported files, print spooler output, or scheduled reports. The database trigger and ETL export pattern works well here. If you have direct database access (even read-only), a middleware service can query the database on a schedule, identify contacts needing communication, and call the CPaaS API without any modification to the legacy application itself.

Build a status callback (webhook) endpoint in your middleware that receives delivery events from the CPaaS platform: delivered, failed, opted out, invalid number. Write those statuses back to a field in your legacy database or a separate tracking table. For failed deliveries, implement a retry queue with exponential backoff for transient failures (network timeout, carrier unavailable) and permanent suppression for hard failures (invalid number, opt-out). Don't retry hard failures—they generate complaints without producing successful deliveries.

Related Articles