REST versus SMPP, conceptually
A REST API sends messages over standard HTTPS requests — straightforward to integrate from almost any programming language or platform, and a common starting point for most applications. SMPP (Short Message Peer-to-Peer) is a long-running binary protocol connection, typically chosen by higher-volume senders or telecom-adjacent systems that need a persistent, high-throughput session rather than individual HTTP calls. See our SMPP vs REST decision guide for how to choose.
When each is typically considered
- REST: most web and mobile applications, moderate volume, teams that want the fastest integration path
- SMPP: very high message volume, systems already built around telecom protocols, or providers requiring a persistent session for throughput
Sender ID concepts
The sender ID is what the recipient sees as the message source — a business name rather than a long number. Sender IDs generally need to be registered and approved before use; for Digital Connect, sender ID registration is handled through the Interkey parent site — see sender ID registration.
Callbacks and webhooks, conceptually
Rather than polling for status, most integrations register a callback URL that the platform notifies when a message's delivery status changes, or when a reply is received (for two-way use cases). This lets your application react to delivery events in near real time instead of checking repeatedly.
Delivery report states, conceptually
A delivery report typically moves through states such as submitted, delivered, and failed (with a reason code). Designing your application to handle each state — not just "sent" — is what makes features like OTP retry logic or transactional fallback actually reliable; see OTP & Verification and Transactional SMS for where this matters most.
Unicode and multipart SMS
Arabic and other non-Latin scripts are sent using Unicode (UCS-2) encoding, which fits about 70 characters per segment versus 160 for GSM-7 (Latin) text. A message longer than one segment is split into multiple parts and billed accordingly. Plan message templates with this in mind — our SMS length and encoding guide and segment calculator make this concrete.
Integration planning checklist
- Expected message volume and whether REST or SMPP fits better
- Which message types need delivery-status callbacks (OTP, transactional) versus which don't (bulk campaigns)
- Sender ID registered and approved ahead of launch
- Templates checked for Unicode segment length in both Arabic and English
- Fallback behavior defined for failed or undelivered messages
Live API documentation
For real endpoints, authentication, and working code samples in cURL, Python, and Node.js, see the Developers section on our homepage — this page is a planning companion to it, not a replacement.
Frequently asked questions
Should I use REST or SMPP for my integration?
REST suits most applications — it is simpler to integrate and works from any stack. SMPP suits very high-volume senders or systems already built around telecom protocols that need a persistent session. See our SMPP vs REST guide for a closer comparison.
What is a delivery report and why does it matter?
A delivery report tells your application whether a specific message was actually delivered, failed, or is still pending — as opposed to just confirming it was accepted for sending. This matters most for OTP and transactional messages where a silent failure has real consequences.
How do I register a sender ID?
Sender ID registration for Digital Connect is handled through the Interkey parent site — see sender ID registration for the process.
Where do I find actual API endpoints and code samples?
Live endpoints, authentication details, and code samples in cURL, Python, and Node.js are in the Developers section of our homepage. This page covers integration concepts and planning, not the reference documentation itself.