Open APIs for Voice and SMS: You Stay in Control

Most business phone systems are a black box with a nice front end. Calls go in, calls come out, and the data those calls generate — who rang, when, how long, what was said, what happened next — stays locked inside a portal you can look at but not use. If you want to do something the vendor did not think of, you raise a request and wait. We took the opposite view. Every operation you can perform in our portal is available through an open REST API, every event that happens on your account can be pushed to your systems the instant it occurs, and every record we hold about your calls and messages is yours to pull out whenever you want. This is what that surface actually covers across voice and SMS, seven things teams build with it in about a week, the Australian compliance layer that applies once you start sending programmatically, and why openness is a commercial commitment rather than a feature.

Open APIs · Voice & SMS · 2026

Every Call. Every Message. Reachable From Your Own Software

A closed phone platform decides what you are allowed to build and how long you will wait for it. An open one hands you the keys and gets out of the way. This is what our voice and SMS APIs expose, what teams build with them, and why we think open is the only defensible position.

📅 ⏱ 16 min read 🇦🇺 Australian owned, Australian hosted, Australian supported
TL;DR

Everything the portal can do, your code can do. That is the whole principle, and it has four parts. Voice: originate calls from your own application, pull call records and recordings, provision numbers, extensions and users, and route programmatically. SMS: send from your business number, receive inbound messages into your systems, and get delivery status back. Events: webhooks push a payload to your endpoint the moment something happens — call started, answered, missed, voicemail left, message received, transcript ready — so nothing has to be polled. AI data: transcripts and summaries available as structured data, not just as something to read in a portal. What “in control” actually means: your data is exportable in bulk on demand; provisioning does not require a support ticket; your numbers are portable because they are yours; and there is no approval process for building something we did not anticipate. The Australian layer matters: since 1 July 2026 alphanumeric SMS sender IDs must be registered or messages get labelled “Unverified” — so build the compliance in on day one, not after your first campaign underperforms.

What “Open” Actually Means

Nearly every phone provider now claims to have an API. The word does a lot of quiet work, so it is worth defining what we mean by it — and what the alternatives look like in practice.

A closed platform with an APIAn open platform
What is exposedA subset the vendor chose, usually read-only reportingThe operations the portal itself performs
ProvisioningRaise a ticket. WaitAn API call. Seconds
Your call dataViewable in the portal, exportable as a CSV if you are luckyQueryable and exportable in bulk, whenever you want, in a format you can process
Building something newSubmit a feature request into a roadmap you do not controlBuild it. Today. Without asking
Integration approvalPartner programmes, certification, commercial gatekeepingCredentials and documentation
If you leaveYour history stays behindYou take your data and your numbers with you
Why we treat this as a commercial position, not a feature

An API that only exposes what the vendor finds convenient is a permission system wearing an engineering costume. It lets a provider say yes to the question while retaining the ability to say no to everything specific. The test of an open platform is not whether an API exists — it is whether you can do something the vendor never anticipated, without asking. That is the commitment, and everything below follows from it.

There is a self-interested version of this argument and we will make it honestly: a platform that holds your data hostage does not have to be good, because leaving is painful. A platform that hands your data back on request has to earn the renewal every year. We would rather compete on the second basis.

The Surface, End to End

Four families of capability. Most teams start with one and add the others as they find uses for them.

📞

Voice operations

Originate a call from your own application, query call detail records, retrieve recordings, and control routing behaviour. Everything from a click-to-call button on your CRM to an automated outbound workflow.

💬

Messaging operations

Send SMS from your business number, receive inbound replies delivered to your systems, and get delivery status back so your application knows what actually landed.

🔧

Account and provisioning

Order numbers, create extensions and users, adjust routing, manage queues. The things that traditionally required a support ticket at a telco, done from your code in seconds.

📡

Events and AI data

Webhooks that push call and message events to your endpoint as they occur, plus access to AI-derived transcripts and summaries as structured data rather than as something to read on a screen.

On the examples in this article

The payload shapes and field names shown below are illustrative — they show the pattern rather than a literal contract. Exact resource paths, field names, authentication details, rate limits and versioning are in the developer documentation issued with your API credentials. Ask for the docs before you commit to an architecture; any provider unwilling to show them before you sign is telling you something.

Voice: Calls, Numbers and Records

Voice is the part most often locked down elsewhere, because it is where the vendor's own product lives. Four things matter.

CapabilityWhat it doesWhat it is used for
Click-to-call originationYour application asks the platform to connect a user to a number. The user's device rings, then the destinationDial buttons in a CRM, a web app or an internal tool. Removes mis-dials and captures every call against a record automatically
Call detail recordsQuery calls by time, number, user, direction, duration and outcomeCustom reporting, wallboards, feeding a data warehouse, attribution, invoicing clients for time on calls
Recordings and transcriptsRetrieve the audio, and where AI transcription is enabled, the text and a structured summaryCompliance archives, quality review, writing call notes into a CRM automatically
Numbers, users and routingOrder a number, create a user, change where a number points, adjust a queueOnboarding automation, multi-site rollouts, campaign numbers spun up and torn down programmatically
The one that changes how a business operates

Provisioning without a ticket. At a traditional telco, adding a number or a user is a request that goes into a queue and comes back in days. When it is an API call, a new staff member can be fully provisioned by your HR system the moment their start date arrives — extension, number, queue membership, app login — and de-provisioned automatically when they leave. That second half is a security control, not a convenience. Offboarding is the step everyone forgets manually and nobody forgets when it is automated.

SMS: Send, Receive, and Know

Messaging over an API is deceptively simple to start and easy to get wrong at scale. Three capabilities, and a fourth thing that separates a real implementation from a demo.

CapabilityDetail
Outbound sendPost a message with a destination, a body and the sending identity. Long messages concatenate; unicode changes the segment length, which affects cost — worth handling in your code rather than discovering on an invoice
Two-way receiveInbound messages to your business number delivered to your systems as they arrive. This is what turns SMS from a broadcast channel into a conversation, and it is the half most implementations skip
Delivery statusStatus updates telling you what was accepted, delivered, or failed and why. Without this you are sending into the dark and assuming it worked
Sender identityWhether the message shows a number or your registered business name. In Australia this now carries a regulatory obligation — see the compliance section below
The mistake that costs the most

Sending without handling replies. If a customer can receive a message from your business, they will reply to it — with a question, a reschedule, or STOP. An outbound-only implementation produces a channel where customers talk and nobody listens, which is worse for the relationship than not messaging at all. Wire up inbound on day one, even if all it does initially is drop the message into a shared inbox and notify someone.

Practical note on the two-way path: the same number your customers ring should be the number they can message. Splitting voice and SMS across different identities confuses people and quietly halves your response rate. Our guide to business SMS from your phone system covers the non-API side of the same channel.

Events: Your Systems, the Instant It Happens

Everything above is your code asking us a question. Webhooks are us telling you something without being asked, which is the difference between a system that reports and a system that reacts.

When something happens on your account, we post a payload to a URL you nominate. Illustrative shape:

FieldExample valueWhy you want it
eventcall.missedWhat happened. Your handler switches on this
call_ida1b2c3…Ties every event about one call together, and ties back to the record and recording
from / to+61…Look the caller up in your CRM before doing anything else
directioninboundDifferent handling for calls you made versus calls you received
timestampISO 8601, UTCOrdering, deduplication and reporting
durationsecondsPresent on completion events

The event types that carry the most value in practice:

EventWhat teams do with it
Call started / answeredScreen pop the customer record before the second ring. The single most-noticed integration by customers, because it turns “can I take your name?” into “morning Sarah”
Call missedFire an automatic SMS offering a callback, create a task, alert a channel. For trades and service businesses this is routinely the highest-return automation in the entire stack
Voicemail leftPush the audio and transcription straight into a ticket or CRM record so nobody has to listen to a mailbox
Message receivedRoute an inbound SMS to the right person or queue, or into your helpdesk as a conversation
Transcript readyWrite the call notes and follow-up actions into the customer record automatically. This is the one that removes admin nobody was doing anyway
Three things to build into any webhook consumer

Verify the signature so you only act on payloads that genuinely came from us. Respond fast and process asynchronously — acknowledge, queue, then do the work, because slow handlers cause retries. And expect duplicates: any at-least-once delivery system will occasionally send an event twice, so make your handler idempotent using the event or call identifier. These three account for the overwhelming majority of integration bugs we see.

What Staying in Control Means

“You stay in control” is easy to write on a website. Here is what we mean by it, stated as commitments you can test.

📤

Your data is yours, in bulk

Call records, recordings, transcripts and message history are exportable on demand, in a machine-readable form. Not a screenshot, not a paginated portal view, not a fee.

🎫

No ticket for routine change

Numbers, users, extensions and routing are yours to provision. A platform that makes you ask permission to add a user has made itself a bottleneck in your business.

🔓

No approval to build

There is no certification programme standing between you and a working integration. Credentials and documentation, then build whatever your business actually needs.

🔁

Your numbers are portable

Under the industry Local Number Portability framework your numbers belong to your business. An API-first platform should make leaving technically easy, and we do.

🇦🇺

Australian infrastructure

The platform and the network are ours and they are here. That matters for latency, for support escalation, and for answering the question of where your call data is processed.

🧰

No code is a first-class path too

Not every team has developers. Zapier, Make and Power Automate reach the same triggers and actions, so the same events drive automation without anyone writing a line.

Ask any provider these four questions

Can I export all my call records and recordings, in bulk, without asking? Can I provision a number and a user from the API? Can I see the API documentation before I sign? Is there an approval process for a custom integration? The answers separate open platforms from platforms with an API, and none of them require a technical conversation.

Ask for the API documentation. Read it before you decide anything.

Uniden Voice runs on an open REST API with webhook events across voice, SMS, numbers, users and AI transcripts — Australian owned, Australian hosted, Australian supported. We will send you the developer documentation, issue sandbox credentials, and walk your team through the events that matter for what you are building. No certification programme, no partner tier, no gatekeeping.

Get API Access Or call 1300 881 662

Seven Things Teams Build in a Week

None of these are ambitious. All of them are things businesses tell us paid for themselves quickly.

#What it doesHow
1Missed-call auto-response. An unanswered call triggers an immediate SMS offering a callbackMissed-call webhook → send SMS. About twenty lines of code, and the highest return of anything on this list
2Appointment reminders that accept replies. Reminder goes out the day before; the customer can reply to confirm or rescheduleScheduled send from your booking system + inbound message webhook to process the reply
3Screen pop. The customer record opens before anyone picks upCall-started webhook → look up by number → open the record in your CRM
4Automatic call notes. Every call writes itself to the customer record with a summary and actionsTranscript-ready webhook → write to CRM. Removes admin that mostly was not happening anyway
5Starter and leaver automation. HR system provisions and de-provisions phone accessProvisioning API calls triggered by your HR platform. The offboarding half is a genuine security control
6Campaign attribution. Different numbers on different campaigns, all reporting into one placeProvision numbers via API, query call records, join on the number. You finally know which spend generates calls rather than clicks
7Operational alerting. A queue exceeds a wait threshold and the right person is told immediatelyCall events into your monitoring or chat tool. Turns a report you read on Friday into an intervention on Tuesday
4
Capability families
7
Builds inside a week
0
Approvals required
1
Company behind all of it

Number one deserves emphasis because of how disproportionate it is. A missed call is a customer who wanted to buy something and could not reach you. An SMS arriving twenty seconds later — before they have rung the next business on the list — converts a meaningful share of them. It is roughly a morning's work. The arithmetic on missed calls makes the case better than we can here.

The Australian Layer

Once you are sending programmatically you are operating at a scale where Australian rules apply properly. None of this is difficult — but it is far cheaper to build in at the start than to retrofit.

RequirementWhat appliesBuild it in as
SMS Sender ID RegisterSince 1 July 2026, alphanumeric sender IDs — your business name at the top of a message — must be registered before use with Australian mobile numbers. Messages sent using unregistered branded sender IDs are labelled “Unverified”. Registration is completed through a participating telco or messaging providerRegister the sender IDs you intend to use before you write the send code. Treat an unregistered sender ID as a configuration error, not a warning
ConsentThe Spam Act 2003 requires consent for commercial electronic messages, whether express or reasonably inferredStore the consent basis and its timestamp against the contact, and have your send path check it. Transactional messages and marketing are not the same thing — but your code needs to know which is which
Identify the senderCommercial messages must clearly identify who sent them and how to contact themA template rule, enforced centrally rather than left to whoever writes each message
UnsubscribeA functional, low-cost unsubscribe facility that is honouredHandle STOP in your inbound webhook, suppress at the send layer, and make suppression global rather than per-campaign
Voice marketingThe Do Not Call Register applies to telemarketing calls, with its own washing obligations and permitted exemptionsWash your outbound lists before any automated dialling, and log that you did
Emergency callsProgrammatic call origination must never sit between someone and an emergency serviceExclude emergency numbers from any automated flow, and verify service addresses per site
Build suppression at the send layer, not the campaign layer

The most common and most expensive compliance failure in API messaging is an opt-out honoured in one system and not another, so a customer who replied STOP receives the next campaign from a different code path. Put the check in the one function every message goes through. If there is more than one way to send a message in your codebase, that is the actual bug.

Our detailed treatments: the SMS Sender ID Register, what the “Unverified” label means, and outbound calling and the Do Not Call Register.

Where This Goes Next

One development is worth planning for, because it changes what your call data is worth.

AI agents are moving from answering questions to taking actions, and they need a standard way to reach business systems. The Model Context Protocol has emerged as the common language for that — a way for an AI assistant to discover and use the tools and data a business exposes. The implication for phone platforms is direct.

If your call data is…Then…
Locked in a vendor portalIt is invisible to any AI agent you deploy, and to any analysis you might want to run. It might as well not exist
Available through an open API, structured, with transcriptsIt becomes one of the richest sources you have about what customers actually want — and it is reachable by the tools you are going to build next
The quiet argument for openness

Your phone calls are the highest-quality customer research your business generates. People ring and tell you what they need, what confused them, and what your competitor quoted. A closed platform throws that away every day. An open one turns it into an asset that compounds — and the moment AI agents can reach it, the gap between those two positions stops being philosophical and starts being commercial.

To go further: 1,000+ integrations and open APIs covers the four connection methods and when to use each, Australian SaaS platforms and how each connects covers the specific software you are probably running, and AI transcription and CRM notes covers the data the transcript events produce.

Frequently Asked Questions

What can you do with a voice and SMS API?
Four families of capability, and most teams start with one then add the others. Voice operations let you originate calls from your own application, which is what powers a click-to-call button in a CRM or internal tool, along with querying call detail records by time, number, user, direction, duration and outcome, retrieving recordings, and controlling routing. Messaging operations let you send SMS from your business number, receive inbound replies delivered into your systems, and get delivery status back so your application knows what actually landed rather than assuming it did. Account and provisioning operations let you order numbers, create extensions and users, adjust routing and manage queues — the things that traditionally required raising a support ticket with a telco and waiting days, done from code in seconds. And events and AI data cover webhooks that push call and message events to your endpoint as they occur, plus access to AI-derived transcripts and summaries as structured data rather than as something you read on a screen. The underlying principle is that everything the portal can do, your code can do.
What does an open phone system API actually mean?
It means the API exposes the operations the portal itself performs, rather than a subset the vendor found convenient to publish. The practical differences are easy to test. On a closed platform, provisioning means raising a ticket and waiting, your call data is viewable in a portal and exportable as a CSV if you are lucky, building something new means submitting a feature request into a roadmap you do not control, integrations may require partner programmes or certification, and if you leave, your history stays behind. On an open platform, provisioning is an API call that completes in seconds, your data is queryable and exportable in bulk whenever you want in a format you can process, you build what you need today without asking, there is no approval process standing between you and a working integration, and you take your data and your numbers with you if you go. The honest test is not whether an API exists — nearly every provider claims one — but whether you can do something the vendor never anticipated without seeking permission. An API that only exposes what the vendor finds convenient is a permission system in engineering clothing.
What should I build first with a phone system API?
A missed-call auto-response, because the return is disproportionate to the effort. When a call goes unanswered, the missed-call webhook fires and your handler sends an immediate SMS offering a callback — roughly twenty lines of code and about a morning's work. The reason it matters is that a missed call is a customer who wanted to buy something and could not reach you, and a message arriving twenty seconds later, before they have rung the next business on their list, converts a meaningful share of them. After that, six more are commonly built inside a week: appointment reminders that accept replies, combining a scheduled send from your booking system with an inbound message webhook to process confirmations and reschedules; screen pop, using the call-started webhook to look up the number and open the record before anyone picks up; automatic call notes, using the transcript-ready webhook to write summaries and actions into the CRM; starter and leaver automation driven by your HR platform, where the offboarding half is a genuine security control; campaign attribution using numbers provisioned per campaign and joined against call records; and operational alerting when a queue exceeds a wait threshold.
How do webhooks work for call and SMS events?
Instead of your code repeatedly asking whether anything has happened, the platform posts a payload to a URL you nominate the instant an event occurs. A typical payload identifies the event type such as a missed call, a call identifier that ties every event about one call together and links back to the record and recording, the from and to numbers so you can look the caller up before doing anything else, the direction, a timestamp for ordering and deduplication, and a duration on completion events. The event types that carry the most value are call started or answered for screen pop, call missed for auto-response and task creation, voicemail left for pushing audio and transcription into a ticket, message received for routing inbound SMS to the right person or queue, and transcript ready for writing call notes automatically. Three things belong in any webhook consumer and account for most integration bugs: verify the signature so you only act on genuine payloads, respond fast and process asynchronously because slow handlers cause retries, and expect duplicates by making your handler idempotent on the event or call identifier, since any at-least-once delivery system will occasionally send an event twice.
What Australian rules apply to sending SMS through an API?
Six, and all are cheaper to build in at the start than to retrofit. Since 1 July 2026 the SMS Sender ID Register applies: alphanumeric sender IDs, meaning your business name displayed at the top of a message, must be registered before use with Australian mobile numbers, and messages sent using unregistered branded sender IDs are labelled Unverified. Registration is completed through a participating telco or messaging provider, and you should register the sender IDs you intend to use before writing the send code, treating an unregistered one as a configuration error rather than a warning. The Spam Act 2003 requires consent for commercial electronic messages, whether express or reasonably inferred, so store the consent basis and timestamp against the contact and have your send path check it. Commercial messages must clearly identify the sender and how to contact them, which is best enforced as a central template rule. You must provide a functional low-cost unsubscribe that is honoured, so handle STOP in your inbound webhook and suppress globally at the send layer. The Do Not Call Register applies to telemarketing calls with washing obligations. And programmatic call origination must never sit between someone and an emergency service.
How do I avoid compliance failures in API messaging?
Put the suppression check in the one function that every outbound message passes through, rather than in each campaign or workflow. The most common and most expensive failure in API messaging is an opt-out honoured in one system but not another, so a customer who replied STOP still receives the next campaign because it was sent from a different code path. If there is more than one way to send a message in your codebase, that is the actual defect — the fix is architectural rather than procedural. Alongside that, make suppression global rather than per-campaign, since a customer who opts out of marketing has not opted into receiving the same marketing under a different campaign name. Store the consent basis and its timestamp on the contact record so that you can demonstrate why any given message was sent, and make your send path check it rather than trusting the caller. Enforce sender identification centrally through templates instead of leaving it to whoever writes each message. And handle inbound replies from day one, because an outbound-only implementation creates a channel where customers talk and nobody listens, which is worse for the relationship than not messaging at all.
Why does open API access matter when choosing a phone provider?
Because it determines both what you can build and what happens to your data. Your phone calls are the highest-quality customer research your business generates — people ring and tell you what they need, what confused them and what a competitor quoted — and a closed platform discards that every day, while an open one turns it into an asset that compounds. There is also a straightforward commercial dimension worth stating plainly: a platform that holds your data hostage does not have to be good, because leaving is painful, whereas a platform that hands your data back on request has to earn the renewal every year. The forward-looking reason is that AI agents are moving from answering questions to taking actions, and the Model Context Protocol has emerged as the common language for reaching business systems and data. If your call data sits locked in a vendor portal it is invisible to any AI agent you deploy and to any analysis you want to run. Four questions test any provider: can I export all call records and recordings in bulk without asking, can I provision a number and a user from the API, can I see the documentation before signing, and is there an approval process for a custom integration.

What to Read Next

Your next reads

Uniden Voice Over Cloud logo

Australia’s smartest AI-powered cloud phone system — Australian owned, Australian hosted, Australian supported. unidenvoice.com | 1300 881 662