The Gap Between Knowing and Doing
Every business runs on systems that know things. The booking platform knows tomorrow's appointments. The job management app knows the part arrived. Accounting knows which invoice is nine days late. The phone system knows a call came in at 4:52pm and nobody picked it up.
In most Australian businesses, none of that knowledge does anything on its own. It sits in a screen, waiting for a person to look at it, notice, and act.
The information arrives instantly. The action waits on someone's attention. Everything that goes wrong in customer follow-up lives in that gap.
| Your system knows | What usually happens | What should happen |
|---|---|---|
| A call came in and nobody answered | It appears in a report on Friday | An SMS goes out in twenty seconds offering a callback |
| An appointment is tomorrow at 9am | Someone rings around, if they get to it | A reminder goes out automatically, and the customer can reply to reschedule |
| The part arrived this morning | The customer finds out when they chase | They are told the moment it is scanned in |
| A new staff member starts Monday | Someone raises a ticket for a phone extension | The extension, number and app login exist before they arrive |
| A customer is on the phone right now | “Can I take your name?” | Their record is already open when the handset is picked up |
None of the right-hand column is ambitious engineering. All of it requires one thing: a phone platform your own software is allowed to drive.
One Principle
Every provider says they have an API. The word covers a wide range of sins, so here is the principle we hold ourselves to, stated plainly enough to be tested:
If the portal can do it, your code can do it
Not a read-only reporting endpoint. Not a curated subset. The operations that our own interface performs are the operations available to you — placing calls, pulling records and recordings, retrieving transcripts, ordering numbers, creating users, changing routing, sending and receiving messages. The test of an open platform is whether you can build something the vendor never anticipated, without asking permission.
| Area | What is reachable |
|---|---|
| Calls | Originate a call from your application — the basis of click-to-call in a CRM, a web app or an internal tool |
| Records | Query calls by time, number, user, direction, duration and outcome. Feed a warehouse, build a wallboard, attribute a campaign |
| Recordings and transcripts | Retrieve audio, and where AI transcription is on, the text and a structured summary |
| Numbers and users | Order a number, create an extension, add someone to a queue, change where a number points |
| Messaging | Send from your business number, receive inbound replies, and get delivery status back |
| Events | Webhooks pushed to your endpoint as things happen, rather than you asking repeatedly |
About the examples in this article
Field names and payload shapes below are illustrative of the pattern, not a literal contract. Exact resource paths, authentication, rate limits and versioning live in the developer documentation issued with your credentials. Ask any provider for their API documentation before you sign anything — a refusal to show it in advance is itself an answer.
Five Workflows Worth Wiring First
Ordered by return rather than by sophistication. The first one is not close.
1. Missed call → instant SMS
A call goes unanswered; a message goes out within seconds offering a callback. About a morning's work. A missed call is a customer who wanted to buy and could not reach you — reaching them before they ring the next business on the list converts a meaningful share of them. Nothing else on this list comes close on return per hour of effort.
2. Appointment reminders that accept replies
Your booking system sends the reminder; the customer replies to confirm or reschedule and your system processes it. A day or two. Cuts no-shows, and more importantly it stops reminders being a broadcast the customer cannot answer.
3. Screen pop on inbound
The call-started event fires, your system looks the number up, and the record is open before anyone picks up. A day. Customers read it as competence and it takes real seconds off every enquiry.
4. Calls that write their own notes
When the transcript is ready, the summary and follow-up actions are written into the customer record automatically. A day or two. This removes admin that mostly was not being done, rather than admin that was.
5. Starter and leaver automation
Your HR system provisions the extension, number, queue membership and app login on the start date, and reverses all of it on the last day. Two or three days. The offboarding half is a security control, not a convenience — it is the step everyone forgets manually.
Bonus: campaign attribution
Provision a number per campaign through the API, then query call records and join on the number. Half a day. You stop guessing which marketing produces phone calls rather than clicks.
Notice that four of the six are event handlers rather than integrations in any heavy sense. That is the shape of most useful work here: something happens, a payload arrives, your code does one thing.
The Event Stream
Querying an API means asking a question. Webhooks mean being told — and that difference is what separates a system that reports from a system that acts.
When something happens on your account, we post a payload to a URL you nominate. The useful events, and what businesses do with them:
| Event | Typical use |
|---|---|
| Call started / answered | Screen pop before the second ring. Log the call against the customer as it begins rather than afterwards |
| Call missed | Automatic SMS, task creation, alert to a chat channel. The highest-value event in the set for most businesses |
| Voicemail left | Push the audio and its transcription into a ticket or CRM record so nobody checks a mailbox |
| Message received | Route an inbound SMS to the right person, queue or helpdesk conversation |
| Transcript ready | Write notes, actions and outcome into the customer record automatically |
| Call ended | Duration and outcome for reporting, billing clients for time, or triggering a follow-up sequence |
A payload carries enough to act on immediately — the event type, an identifier tying every event about one call together, the numbers involved, direction, timestamp and, on completion, duration.
Three things every webhook consumer needs
Verify the signature, so you only act on payloads that genuinely came from us. Acknowledge fast and process asynchronously — take the payload, queue it, then do the work, because a slow handler triggers retries. And make it idempotent: any at-least-once delivery system will occasionally send the same event twice, so key your processing on the event or call identifier. Those three account for nearly every integration bug we help people debug.
The Half Everyone Skips
Most SMS implementations are outbound only. Messages go out; replies go nowhere. It is the single most common design flaw in business messaging and it is worth being blunt about the consequence.
| What the customer does | Outbound-only | Two-way |
|---|---|---|
| Replies “can we make it Thursday?” | Nothing. Nobody sees it | Routed to the right person or straight into the booking system |
| Replies with a question about the job | Nothing | Lands in a shared inbox with the customer's history attached |
| Replies STOP | Nothing — and you keep messaging them | Suppressed globally, immediately |
| Replies “yes” to confirm | Nothing, so someone rings to confirm anyway | Booking marked confirmed. The call never needs to happen |
Wire up inbound on day one, even crudely
It does not have to be clever to start. If all your inbound handler does initially is drop the message into a shared inbox and notify someone, you have already fixed the worst version of this — a channel where customers talk and nobody listens. Sophistication can come later; listening cannot.
One related design point: the number your customers ring should be the number they can message. Splitting voice and messaging across different identities confuses people and quietly halves your reply rate. Our guide to business SMS from your phone system covers the same channel from the non-technical side.
Control, Stated as Commitments
“You stay in control” is a slogan unless it is expressed as things you can check. Here are ours.
Bulk export, on demand
Call records, recordings, transcripts and message history, in a machine-readable form, whenever you want them. Not a paginated portal view. Not a fee. Not a request you have to justify.
No ticket for routine change
Numbers, users, extensions, queues and routing are yours to provision through the API. A platform you have to ask permission to add a user to has made itself a bottleneck in your business.
No approval to build
No certification programme, no partner tier, no commercial gate between you and a working integration. Credentials, documentation, build what you need.
Numbers you can take with you
Under the industry Local Number Portability framework your numbers belong to your business. We think a platform should be technically easy to leave — that is what makes staying a choice rather than a trap.
Ours, and here
We own and operate our own network. The platform, the calls and the support are the same company in the same country, which matters for latency, for escalation, and for answering where your data is processed.
Documentation before you sign
You should be able to read exactly what is exposed before committing to an architecture. We will send it, with sandbox credentials, before there is a contract.
The honest self-interested version
A platform that holds your data does not have to be good, because leaving hurts. A platform that hands your data back on request has to be good, because leaving is easy. We would rather compete on the second basis — and if that sounds like marketing, test it with the four questions: bulk export without asking, provisioning from the API, documentation before signing, and whether custom integrations need approval.
You Do Not Need Developers
Most Australian businesses reading this do not have an engineering team, and the good news is that the same event stream drives no-code automation platforms.
| What you want | With code | Without code |
|---|---|---|
| Missed call sends an SMS | A webhook handler, about twenty lines | A trigger and an action in Zapier or Make. Minutes |
| Call summary into the CRM | Transcript event → your CRM's API | A two-step automation using existing connectors |
| Inbound SMS into a shared inbox | Inbound webhook → your helpdesk | A connector, configured once |
| Alert when a queue backs up | Events into your monitoring stack | An action posting into Teams or Slack |
| Number provisioned per campaign | An API call from your marketing tooling | Usually still worth doing in the portal — it takes seconds |
6
Event types worth handling
5
Workflows worth building first
0
Approvals to build anything
1
Company behind platform and network
The practical advice: start in a no-code tool, prove the workflow is worth having, and only move it into code when volume or complexity justifies it. Plenty of businesses never need to make that second move. Our guide to the four connection methods covers when each is the right choice.
The Compliance Floor
Sending programmatically puts you at a scale where Australian rules apply properly. Build these in from the start — retrofitting them is significantly more expensive.
| Requirement | What it means for your build |
|---|---|
| SMS Sender ID Register — mandatory since 1 July 2026 | Alphanumeric sender IDs, meaning your business name displayed at the top of a message, must be registered before use with Australian mobile numbers, and unregistered ones cause messages to be labelled “Unverified”. Register through a participating telco or messaging provider before you write the send code, and treat an unregistered sender ID in configuration as an error rather than a warning |
| Consent — Spam Act 2003 | Commercial electronic messages require consent, express or reasonably inferred. Store the basis and the timestamp on the contact, and have the send path check it rather than trusting the caller |
| Sender identification | Commercial messages must clearly identify who sent them and how to reach them. Enforce this in a central template rather than leaving it to whoever writes each message |
| Unsubscribe | A functional, low-cost opt-out that is actually honoured. Handle STOP in the inbound webhook and suppress globally, not per campaign |
| Do Not Call Register | Applies to telemarketing calls, with washing obligations and defined exemptions. Wash lists before any automated dialling, and log that you did |
| Emergency calls | Programmatic origination must never sit between a person and an emergency service. Exclude emergency numbers from automated flows and verify service addresses per site |
Put suppression in one place
The most expensive failure in API messaging is an opt-out honoured in one system and not another, so someone who replied STOP receives the next campaign because it was sent from different code. The check belongs in the single function every message passes through. If there is more than one way to send a message in your stack, that is the real defect — and it is architectural, not procedural.
Detail where you need it: the SMS Sender ID Register and the outbound calling mistakes that cost money.
The Asset You Are Accumulating
One last argument, and it is the one that will matter most in two years.
Your phone calls are the best customer research your business generates. People ring and tell you, unprompted and for free, what they need, what confused them, what a competitor quoted and why they nearly did not call. Most businesses destroy that within seconds of the handset going down.
| If your call data is… | Then… |
|---|---|
| Trapped in a vendor portal | It cannot be analysed, cannot be joined to anything else, and is invisible to any AI tool you deploy. Functionally it does not exist |
| Structured, transcribed and reachable by API | It compounds. Every month adds to something you can query, and the tools that can read it are getting better fast |
That second row is why openness has stopped being a philosophical preference. AI agents are moving from answering questions to taking actions, and the Model Context Protocol has emerged as the common way for them to reach business systems and data. A complete, structured, onshore record of what your customers actually said on the phone is exactly the kind of asset those tools are built to use — and it only exists if your platform lets you keep it.
Where to start, honestly
Build the missed-call SMS. One event, one action, about a morning. It will pay for the effort within weeks and it will tell you more about whether this approach suits your business than any amount of further reading. Everything else on this page is available whenever you are ready for it.
Further reading: the four ways to connect a phone system, how Australian SaaS platforms connect, and what AI transcription and CRM notes actually produce.
Frequently Asked Questions
What can I do with an open voice and SMS API?
Drive the phone system from your own software instead of waiting for a person to act. On the voice side you can originate calls from your application, which is what powers click-to-call in a CRM or internal tool; query call records by time, number, user, direction, duration and outcome to feed reporting, a warehouse or campaign attribution; retrieve recordings and, where AI transcription is enabled, the text and a structured summary; and provision numbers, extensions, users, queues and routing without raising a support ticket. On the messaging side you can 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. On top of both sits an event stream: webhooks push a payload to a URL you nominate the instant a call starts, is answered or is missed, a voicemail is left, a message arrives or a transcript becomes ready, so your systems react rather than poll. The governing principle is that any operation available in the portal is available through the API — including operations the vendor never anticipated you wanting.
What should I build first with a phone API?
The missed-call SMS, and it is not a close contest. When a call goes unanswered the missed-call event fires and your handler sends an immediate message offering a callback. It is roughly a morning's work — one event, one action — and the reason the return is so disproportionate is that a missed call is a customer who wanted to buy something and could not reach you, so a message arriving within seconds, before they have rung the next business on their list, recovers a meaningful share of them. After that, four more are worth doing in order. Appointment reminders that accept replies, combining a scheduled send from your booking system with an inbound webhook to process confirmations and reschedules, which takes a day or two. Screen pop, where the call-started event triggers a lookup so the customer record is open before anyone picks up, about a day. Calls that write their own notes, where the transcript-ready event writes the summary and actions into the customer record, a day or two. And starter and leaver automation driven by your HR system, two or three days, where the offboarding half is a genuine security control rather than a convenience.
Why do two-way SMS instead of outbound only?
Because if a customer can receive a message from your business, they will reply to it, and an outbound-only implementation creates a channel where customers talk and nobody listens — which is worse for the relationship than not messaging at all. Consider what happens in each case. A customer replies asking to move the appointment to Thursday: outbound-only, nothing happens and nobody sees it; two-way, it routes to the right person or straight into the booking system. A customer replies with a question about the job: outbound-only, nothing; two-way, it lands in a shared inbox with their history attached. A customer replies STOP: outbound-only, nothing happens and you keep messaging them, which is both a poor experience and a compliance failure; two-way, they are suppressed globally and immediately. A customer replies yes to confirm: outbound-only, someone rings to confirm anyway, so the automation saved nothing. The important point is that inbound handling does not need to be clever to start — if all it does initially is drop the message into a shared inbox and notify someone, you have fixed the worst version of the problem.
How do webhooks work and what can go wrong?
Rather than your code repeatedly asking whether anything has happened, the platform posts a payload to a URL you nominate the moment an event occurs. A payload carries enough to act on immediately: the event type, an identifier tying every event about one call together, the numbers involved, the direction, a timestamp and, on completion events, the duration. The most useful events are call started or answered for screen pop and live logging, call missed for automatic SMS and task creation, voicemail left for pushing audio and transcription into a ticket, message received for routing inbound SMS, transcript ready for writing notes automatically, and call ended for reporting or triggering follow-up sequences. Three things belong in any webhook consumer and between them account for nearly every integration bug worth debugging. Verify the signature so you only act on payloads that genuinely came from the platform. Acknowledge quickly and process asynchronously — take the payload, queue it, then do the work, because a slow handler triggers retries. And make your handler idempotent by keying on the event or call identifier, because any at-least-once delivery system will occasionally deliver the same event twice.
What does it mean to stay in control of your phone platform?
Six things, all of which can be tested rather than taken on trust. Bulk export on demand: call records, recordings, transcripts and message history available in a machine-readable form whenever you want them, not as a paginated portal view, not for a fee, and not as a request you have to justify. No ticket for routine change: numbers, users, extensions, queues and routing provisioned through the API, because a platform you must ask permission to add a user to has made itself a bottleneck in your business. No approval to build: no certification programme, partner tier or commercial gate between you and a working integration. Numbers you can take with you, since under the industry Local Number Portability framework your numbers belong to your business, and a platform should be technically easy to leave so that staying is a choice rather than a trap. A provider that owns and operates its own network, so the platform, the calls and the support are one company in one country. And documentation available before you sign, so you can see exactly what is exposed before committing to an architecture.
Do I need developers to use a phone system API?
No, because the same event stream drives no-code automation platforms such as Zapier, Make and Power Automate. A missed call sending an SMS is about twenty lines of code with a webhook handler, or a trigger and an action configured in minutes without code. Getting a call summary into the CRM is a transcript event posting to your CRM's API, or a two-step automation using existing connectors. Routing inbound SMS into a shared inbox is an inbound webhook to your helpdesk, or a connector configured once. Alerting when a queue backs up is call events into your monitoring stack, or an action posting into Teams or Slack. Provisioning a number per campaign is an API call from your marketing tooling, though it is usually still worth doing in the portal because it takes seconds. The practical advice is to start in a no-code tool, prove the workflow is actually worth having, and only move it into code when volume or complexity justifies the move — plenty of businesses never need to make that second step at all.
What Australian rules apply when sending SMS from an API?
Six, and building them in from the start is far cheaper than retrofitting. Since 1 July 2026 the SMS Sender ID Register applies, so alphanumeric sender IDs — your business name displayed at the top of a message — must be registered before use with Australian mobile numbers, and unregistered ones cause messages to be labelled Unverified; register through a participating telco or messaging provider before writing the send code, and treat an unregistered sender ID in configuration as an error rather than a warning. Under the Spam Act 2003 commercial electronic messages require consent, express or reasonably inferred, so store the basis and timestamp against the contact and have the send path check it rather than trusting the caller. Commercial messages must clearly identify the sender and how to reach them, enforced in a central template. You must provide a functional low-cost unsubscribe that is honoured, handled in the inbound webhook and suppressed globally rather than per campaign. The Do Not Call Register applies to telemarketing calls with washing obligations. And programmatic origination must never sit between a person and an emergency service.
