Interkey products
Interkey Digital Connect is Interkey’s enterprise messaging platform: one integration for OTP and two-factor delivery, transactional alerts, mass notifications and campaign messaging, across SMS, WhatsApp, Messenger, Instagram, web chat and in-app messaging, with sender identities registered and traffic terminated on the Saudi mobile networks.
Orientation
The whole page in one table, before the detail.
| Product | Interkey Digital Connect, an Interkey product |
|---|---|
| Messaging channels | SMS, WhatsApp, Facebook Messenger, Instagram, website live chat, in-app mobile chat |
| Integration | REST API for application traffic; SMPP for high-volume SMS; SOAP where an existing business system needs it |
| Platform controls | Role-based access with two-factor authentication, IP whitelisting, approved templates, campaign scheduling |
| Commercial model | Quote only: priced by channel mix and volume |
One integration
A Saudi bank, retailer or government service talks to its customers across at least five channels: an OTP by SMS, a delivery notification by WhatsApp, a support conversation starting in an app and continuing on Instagram. Each usually arrives as a separate integration, with its own credentials, its own delivery reporting and its own failure modes.
Digital Connect collapses that into one integration, one set of delivery reporting, and one place to manage the channels and the message types running over them.
One integration
Your business systems
The banking core, the commerce platform, the ERP, the support desk
Digital Connect API
One REST integration, or SMPP for high-volume SMS; one set of delivery reporting
Channels
Saudi operator routes
Traffic terminated onto the Saudi mobile networks, with registered sender identities
Your customer
Reached on the channel they actually use, with delivery you can prove
The channel decision happens per message, not per project: the same integration sends an OTP by SMS, a delivery update by WhatsApp and a support reply into the app, with one view of what was actually delivered.
OTP
A one-time password is the least forgiving traffic on the platform: it is worthless thirty seconds late, and a customer who cannot log in calls the contact centre. Four things decide whether it lands.
Transactional and marketing traffic are not the same product. OTP should run on routes prioritised for it, and you should be told explicitly which class your traffic is on rather than discovering it during an incident.
An unregistered sender is the single most common reason a technically correct OTP integration delivers nothing. Registration is administrative work with the regulator and the operators, and it has to be done before launch, not after the first failed login.
OTP templates are approved content. Changing the wording of a live template without re-approval is a routine way to break delivery on a Friday afternoon. Treat the template as a deployed artefact.
Decide in advance what happens on a failed send: retry, fall back to another channel, or surface a different route to the user. A silent retry loop is not a failure policy, and it is what most integrations ship with.
On “deliverability”, and the number nobody should give you
Deliverability is not a single property of a provider. It is the result of the route class your traffic is on, whether your sender identity is registered, whether your template is approved, and which operator the recipient is on — and it moves. Any provider quoting one blended percentage across all of that, including this one, is quoting an average of conditions that do not apply to you.
Ask instead for the numbers that are actually checkable: delivery receipts exposed per message, reporting broken down by Saudi operator, and the per-segment rate for your own traffic mix in Arabic as well as English. A provider who will show you per-operator receipts is telling you more than one who will quote you a percentage.
Local conditions
A platform that works elsewhere can still fail here, and it fails for the same four reasons every time.
| Condition | What it does to a deployment |
|---|---|
| Sender ID registration | A2P messaging operates under the Communications, Space and Technology Commission, and identities must be registered before traffic terminates reliably. An unregistered sender is a common reason a technically correct integration delivers nothing. That is administrative work with the regulator and the operators, not an API call, and Interkey handles it during onboarding — the sender ID guide sets out who registers and what evidence is asked for. |
| OTP has no tolerance | Most traffic can absorb a delay; the passcode between a customer and their own account cannot. The symptom is not a messaging problem but customers unable to log in. Delivery quality depends on how traffic is routed onto the networks that terminate it and how fast a bad route can be moved. |
| Arabic is UCS-2, not GSM-7 | That roughly halves the characters in one SMS segment, changing both cost and rendering. A platform tested only in English discovers this in production, on its first Arabic campaign, as an invoice. |
| The working week | Traffic peaks Sunday to Thursday, so support built on a Monday-to-Friday calendar is least available when volume is highest. Interkey supports the platform from Riyadh on the Saudi week, in Arabic and English. |
Pricing
No published rate card, for a reason worth stating rather than hiding behind “contact us”: messaging is not one product with one rate. Four things drive what you pay, and only the first is under a vendor’s control.
| Driver | Why it moves the number |
|---|---|
| Channel | SMS, WhatsApp and in-app chat have different cost structures. WhatsApp moved to per-message billing in mid-2025, priced by template category, so cost now depends on the mix of marketing, utility and authentication messages. |
| Destination network | Termination rates differ per operator. A blended per-message rate hides that, which is convenient for whoever quoted it. |
| Length and language | Arabic fits fewer characters per segment than Latin text, so the same sentence in two languages is not the same number of billable segments. |
| Volume and commitment | Sustained volume prices differently from bursty transactional traffic. |
Buying well
What to ask any provider, including this one: the per-segment rate per Saudi operator for your traffic mix, in Arabic as well as English, and whether OTP is priced differently from marketing traffic. A single blended rate across all of that is an average, not a quote, and it will not be what you are invoiced.
When this is the wrong fit: traffic almost entirely outside Saudi Arabia does not need the local operator relationships and registration work that make this platform worth buying. At a few hundred messages a month, any gateway will do.
Next step
Name the channels, the monthly volumes and whether OTP is in scope, and the pricing conversation starts from your traffic mix rather than a rate card.
Registered sender identities
Handled with the regulator and the operators during onboarding
Traffic on Saudi operator routes
Terminated on the Saudi mobile networks
Support on the Saudi working week
Riyadh team, Arabic and English