You describe it. We build the endpoint.
We run your numbers, menus, queues and routing. Your business runs on its own software. Rather than handing you a catalogue of endpoints and wishing you luck, we agree what the integration has to do, confirm it is possible, and build exactly those endpoints.
REST over HTTPS · API key with your account · JSON in, JSON out · any language that can make an HTTP call
Listen to the audio guide
0:00 / 0:00
We run your numbers, your menus, your queues and your routing, while your business runs on its own software, an ERP, a scheduling tool or a custom dashboard. The API connects the two, so your telephony and your software talk to each other.
Our API isn’t one of those generic public libraries with hundreds of endpoints where you get lost for days. It’s private and tailored: you tell us what you want to achieve, we confirm whether it’s feasible and build exactly the endpoints you need, so your developer starts on day one with a working integration.
One of the most powerful uses is real-time routing from your own system. Your scheduling tool knows who’s on duty and when, and your software updates the destination automatically, so calls go to the office during the day, to the on-call mobile in the afternoon and to voicemail in the evening.
You also trigger outbound calls programmatically. Your system starts the call and the recipient hears a recorded or text-to-speech message, ideal for appointment reminders, service alerts or an emergency call that reaches a whole team in seconds.
And you pull your own data to wherever you need it. You download recordings automatically to your own archive or compliance system, and pull call logs, call duration and queue metrics straight into your own dashboards.
Because we build and run our own platform, we extend the API for almost any use case, without depending on a third party. Describe what you want to connect, and we’ll confirm the feasibility and any costs upfront, and deliver working endpoints.
Your API
The endpoints we built for your integration, and the documentation for them.
Your endpoints
4 built to spec · added to as you need them- GET /v1/calls Call log, durations and queue metrics
- GET /v1/recordings/{id} Download a recording to your archive
- PUT /v1/numbers/{id}/destination Change where a number rings, right now
- POST /v1/announcements Place an outbound call that plays a message
Change where the main line rings
CopyWhat that one call did
Your rota tool knows the afternoon shift started at one o’clock. It sends this request, and from that second the main line rings the mobile of whoever is on. At six it sends another and the line goes to voicemail.
- 09:00 Office
- 13:00 Afternoon shift mobile
- 18:00 Voicemail
The logic lives in your software. The telephony runs here.
How we scope it
- You describe the outcome
- We confirm it is feasible
- We build and document it
Depending on complexity a one-off setup fee and/or a monthly maintenance fee applies. Agreed before anyone writes code.
A public API tells you what it can do. It never tells you what you need.
Most providers hand you several hundred endpoints and a documentation site. You find out whether it supports your actual use case somewhere around week three. We start at the other end. Three things follow.
Feasibility before code
You describe the outcome you want. We say yes, no, or “yes but differently” before your developer has written a line. The integrations that die quietly are the ones where that conversation happened too late.
It also means the answer sometimes is “you do not need the API for that”, which is cheaper for everybody.
A surface the size of the job
Your developer gets the endpoints that were agreed, documented, doing exactly what was specified. Four of them, not four hundred, so there is nothing to sift through and nothing to misread.
New requirement later? It becomes another endpoint, scoped the same way.
We built the platform underneath
The IVR platform the API sits on is ours. When something needs extending, we extend it, because there is no third-party vendor whose roadmap decides what is possible.
The honest trade: because it is private, there is no public sandbox to explore at midnight. You get a conversation first, then endpoints that work.
The first month of an integration
Same goal: your rota decides where calls go. Here is how the two approaches spend the first four weeks.
Read, build, discover the limit
- Week one
- reading documentation
- You find the limitation
- after you have built it
- Endpoints to sift through
- hundreds
- Something is missing
- wait for the roadmap
- Headline price
- free
Agree, then build once
- Week one
- a scoping conversation
- You find the limitation
- before you build
- Endpoints to sift through
- the ones you asked for
- Something is missing
- we extend the platform
- Headline price
- a fee, agreed upfront
A conversation, then endpoints
Three steps, and the first one is not a technical one.
You describe the outcome
Not the endpoints, the outcome. “Our rota should decide where the main line rings” or “recordings need to land in our compliance archive every night”.
We confirm and build
We check it is feasible, agree the shape of the data and any fee, then build and document the endpoints. You are not paying for discovery time.
Your developer writes against it
Clean endpoints doing what was agreed, an API key over HTTPS, JSON in and out. Any language that can make an HTTP call is enough.
If the integration keeps growing, with more call logic in your own code, more traffic and requirements nobody else shares, the next step is a dedicated IVR server: your own telephony infrastructure, running only for your business, with full API access. Most integrations never need it, and we will say so.
Four things it is asked for most
And two that sit either side of it, for when the API is not quite the right tool.
Call statistics in your own dashboards
Pull the call log, durations and queue metrics into your BI tool and sit them next to the rest of the business. How many calls each number handled, this week’s average wait, which international number brings in the most.
Recordings into your archive
Download recordings automatically and keep them where your retention policy says they should live: your own storage, a compliance system, or an analysis tool.
Routing your software controls
The rota, the on-call list or the availability toggle in your own tool decides where calls go, and updates the destination as the day moves. The logic stays where it already lives.
Outbound voice alerts
Trigger a call that plays a recorded or generated message: the appointment reminder an hour before the slot, the delivery window, the page to an on-call engineer, the broadcast to a whole team.
Webhook routing, per call
When the decision has to be made call by call rather than set in advance, a webhook asks your system where this particular caller should go, while they are on the line.
Dedicated IVR servers
The step beyond an integration: your own platform instance, unlimited customisation, full API access. Worth it for a handful of customers, and overkill for most.
Come with the outcome, not the endpoint
The scoping conversation goes fastest when it starts from what should happen, in one sentence, rather than from which API call you think you need.
“Our rota should decide where the main line rings” is a good brief. It says what the business wants, leaves the mechanism open, and lets us tell you within a day whether it is a single endpoint, a webhook, or something you do not need us for at all.
“Do you have an endpoint for updating call forwarding?” is a worse one, even though it sounds more technical. It has already assumed the shape of the answer, and if the assumption is wrong the conversation restarts a fortnight later.
Worth saying plainly: this is not free. Depending on complexity there may be a one-off setup fee, a monthly maintenance fee, or both, quoted before anyone writes code. The saving is not on the invoice, it is on the weeks your developer does not spend finding out what is possible.
Five answers and we can scope it
- What should happen, in one sentence
- Which of your systems triggers it, and when
- What data has to cross, in both directions
- How often it runs: per call, hourly or on a change
- Who maintains it on your side once it is live
The last one is the question people skip, and it is the one that decides whether the integration still works in two years.
Tell us what it has to do
Send us the outcome in a sentence or two and we will tell you whether it is an endpoint, a webhook, or something the dashboard already does. If it needs building, you get a scope and a price before any work starts.
Frequently asked questions
A private REST API. We build the endpoints you need from your requirements. You send HTTP requests and get JSON back, so any language or platform that can make an HTTP call will do.
You tell us what you want to achieve. We discuss the requirements, confirm feasibility, and build the endpoints. Your developer receives clean, documented endpoints that do exactly what was agreed. No guesswork, no trial and error.
With an API key that comes with your CallFactory account. All communication runs over HTTPS.
Yes. You can update call destinations in real time. Your own software decides where calls go based on staff availability, caller ID, time of day, or any logic you define.
Yes. The API lets you programmatically initiate calls that play a recorded or text-to-speech message. Useful for appointment reminders, service alerts, and emergency notifications.
Yes. You can automatically retrieve recordings and store them in your own archive, compliance system, or any internal tool.
Yes. The API provides access to call logs, duration data, queue metrics, and more. Pull the raw data into your BI tools and combine it with other business metrics.
Yes. The IVR toolkit is the library of actions our own features are built from: Answer, Play, Dial, Record, GatherDigits and StartStream. Your code calls them during a live call and decides step by step what happens, on the same platform and the same numbers. It suits a development team that wants full control over call behaviour; for a single integration the private API is usually enough.
Our team can build custom API endpoints or complete IVR solutions tailored to your requirements. We build and maintain our own platform, so we can extend it without depending on a third party.
