Austria
Belgium
France
Germany
Italy
Netherlands
Poland
Spain
Sweden
United StatesOur API doesn't have a hundred endpoints. It has yours.
Most providers give you a public API with everything in it, and then you spend two days reading documentation only to find that your particular case isn’t covered. We build our platform ourselves, so you tell us what you need and we add the endpoints.
From a single webhook to your own IVR server — you start where you are now and move up as soon as you need to.
POST /webhook/route
// CallFactory asks on every call:
{ "from": "+447700900123",
"to": "+442079460123",
"time": "2026-09-21T14:32:08Z" }
// your server replies:
{ "destination": "+447700900456",
"whisper": "Customer from Leeds, open ticket" }server unreachable?
fallback to your fixed destination
Your software knows things the phone system doesn't
Who is working today, which customer is calling, whether that order is ready yet: all of it sits in your systems and nowhere in a telephony dashboard.
The rota lives in your planning tool
You know exactly who is on duty, but the phone doesn’t. Every morning someone switches the call forwarding over by hand, or forgets to.
Your figures are in the wrong dashboard
Call logs, call durations and queue figures are kept by us, while your reporting lives with you. As long as the two don’t talk, someone exports a file every month.
What you need isn't on the menu
A call that queries a database, televoting, an outbound alert that reaches an entire team in seconds — none of that fits into any selection menu.
From one request to your server all the way to your own IVR
All four run on the same platform and on your existing numbers. You start where you are now and move up when you need to, not the other way round.
- 1
Webhook routing
server briefly down? fallback to your fixed destinationOn every incoming call we ask your server where the call should go. You reply with a number, a voicemail box or a message, within milliseconds and without the caller noticing a thing. It also works per menu option, with sales going to one webhook and support to another.
Who does what- You build
- one endpoint
- We do
- ask, then execute
- You need
- a server that speaks HTTP
- 2
The private API
feasibility and any costs confirmed upfrontYou pull call recordings, logs and queue figures into your own systems, change destinations from your planning tool and start outbound calls that play a message. There is no public library with hundreds of endpoints: you describe what you want to achieve and we build those endpoints.
Who does what- You build
- the API calls
- We do
- the endpoints, for your case
- You need
- a developer, not a team
- 3
The IVR toolkit
the same building blocks as our own product teamsThe action library we build our own features with: Answer, Play, Dial, Record, GatherDigits, StartStream. Every action has a fixed signature and a typed result, so your code always knows what happened. You write the entire call flow yourself.
Who does what- You build
- the flow
- We do
- the platform underneath
- You need
- a development team
- 4
Your own IVR server
migration from level 2 or 3, your numbers keep runningAn instance that runs for you alone, with guaranteed capacity, your data kept isolated and the programming language your team already uses, whether that is Python, Node or Go. We deliver standard configurations as a Docker container. This is the step for complex flows with database lookups, high-volume campaigns or televoting.
Who does what- You build
- everything, or nothing
- We do
- the server, or the app too
- You need
- a strategy session first
The voice path to your AI
With a single action you stream the live audio of a call to any WebSocket endpoint: an AI assistant, a speech-to-text engine or your own analytics service. You decide when it starts, which way the audio flows and when it stops.
- Caller
- Our number and our routing
- StartStream
- Your AI
Your model, our line
The stream runs alongside the rest of the flow, so in the meantime you can play messages, gather input or transfer the call. A SaaS voicebot can’t offer this, because you have to own the telephony to do it.
Data that never leaves your environment
On your own IVR server the processing stays inside your environment, with a private connection to your database instead of a route over the public internet. That is the set-up heavily regulated sectors need.
We are the licensed operator in fourteen European countries and the United States, and we run our IVR platform ourselves. That is why we can build an extra endpoint instead of pointing you to a vendor’s roadmap, and why the call runs over the fixed telecom network rather than the public internet wherever it can.
Six things no dashboard can handle
Routing based on your own rota
Your server checks who is working right now and returns that number, so there is no second set of records for someone to keep up to date.
Routing based on where the caller is
Your server looks up the area code and returns the nearest branch, without asking the caller anything.
Reading out a status instead of putting the call through
Your server returns text instead of a number: “Your order is ready at three o’clock.” The number becomes an information line.
Recordings straight into your own archive
Downloaded to your own storage or compliance system, without anyone having to fetch them by hand.
An outbound alert to an entire team
Your system starts the calls and the recipients hear a recorded or generated message. For outage alerts and appointment reminders.
A call that queries your database
The caller keys in a customer number, the flow fetches the details and decides what happens next based on them.
When this is the wrong place to start
If all you want is call forwarding, a selection menu or a queue, there is nothing for you here — that is in the dashboard and takes five minutes to set up. This page starts where the dashboard stops. And think in advance about who will maintain the integration: a webhook that goes silent because nobody looks after that server any more is more annoying than the manual forwarding it was meant to replace. That is why level 1 falls back to a fixed destination if your server doesn’t answer.
What developers ask about this
The toolkit comes with documentation and working examples for every action. The private API is different for every customer, so there you get documentation of exactly your endpoints, because a generic reference to a hundred endpoints you don’t have helps nobody.
Your own. A webhook is an HTTP request, so anything that can answer one will work. On your own server you program in Python, Node, Go or whatever your team already uses.
Then the call falls back to the destination you set in advance. An outage on your side shouldn’t cost you a call, which is why you configure that fallback when you set things up and not afterwards.
Yes, and that is the intended order. If you later move to your own server, we migrate your existing flows while your numbers and routing simply keep running.
We deliver a standard configuration of a dedicated server as a Docker container, and it can be running within one working day. Custom work follows a session with our developers, in which we sketch the architecture and tell you what it costs and how long it takes.
What it costs is on the pricing page, and for the private API we confirm feasibility and any costs before we build. You won’t be faced with a surprise after your developer has started.
A private REST API. We build the endpoints you need based on your specific requirements. You send HTTP requests and receive JSON responses, so any programming language or platform that can make HTTP calls will work.
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, so 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 start calls programmatically that play a recorded or text-to-speech message. Useful for appointment reminders, service alerts and emergency notifications.
Yes. You can retrieve recordings automatically and store them in your own archive, compliance system or any internal tool.
Yes. The API gives you 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.
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.
Describe what you want to connect
Tell us which data you need and which actions you want to be able to start. We will tell you whether it can be done, what it costs and which level is the best place to start.
