Skip to main content
VoiceInfra can act as the account an outside app works through. When a third-party app — an AI client, a dashboard, an internal tool your team built — connects to your account, you decide what it may do, and it only ever works in the workspace you pick. This is the inbound direction: an app connecting to VoiceInfra. If you are looking for the opposite — connecting VoiceInfra out to Cal.com, Calendly, Google, or Microsoft — see Integrations.

​
Approving an app

When an app asks for access, the browser opens VoiceInfra’s approval screen. Nothing is shared until you approve.
1

Sign in

Sign in if you are not already. The app is told nothing about you until you allow it.
2

Choose a workspace

Pick which workspace the app should work in. The app sees only this one.
3

Review what it is asking for

Permissions are grouped into areas you will recognise. Each area shows whether the app can view or view and change it, and you can expand any area to see the individual permissions inside.
4

Allow or deny

Allow grants the permissions shown. Deny returns the app to where it came from with access refused.
You can disconnect an app at any time from Connected apps. The app stops working immediately.

​
Reading the permission list

Every area is labelled so you can tell at a glance how much power you are handing over.

​
Allowing changes area by area

Apps usually ask for read access broadly and change access narrowly. Where an area supports it, an Allow changes switch appears on that row — turn it on for the areas you want the app to edit, and leave the rest read-only.
Start read-only. Turn on change access for one area, use the app for a while, and add more later. Reconnecting lets you widen or narrow what it can do.

​
Your role still applies

Granting an app change access does not give it more power than you have. What it can actually change is limited by your role in that workspace — a member cannot grant an app the ability to do something the member could not do themselves.

​
Apps that VoiceInfra has not reviewed

Any app can register itself with VoiceInfra. That is what lets tools like Claude and ChatGPT connect without you creating credentials first. It also means an app’s name and logo prove nothing on their own. When an app registered itself, the approval screen says so, and warns you to continue only if you started the connection yourself and trust the app. If you did not start the connection, deny it.

​
Managing connected apps

Connected apps in the sidebar lists every app you have allowed. For each one you can see:
  • The app’s name and which workspace it acts in
  • When it was added, and when it was last used
  • How many permissions it can view, and how many it can change
  • Every area and permission it holds, grouped the same way as on the approval screen
Disconnect revokes the app immediately. Anyone using it loses access right away and must connect again.

​
Building an app that connects to VoiceInfra

If you are the developer writing the client, the flow is standard OAuth for remote clients:
1

Open the authorization endpoint

Send the user to VoiceInfra’s authorization endpoint with your client ID, redirect URI, and the permissions you want. The user is bounced to sign in if they are not already.
2

Let the user decide

VoiceInfra shows your app’s name, links, and the permissions you requested, grouped into readable areas. The user picks a workspace and approves or denies.
3

Receive the decision

You are redirected back to your registered redirect URI, with an authorization code if the user approved, or an access-denied error if they refused.
4

Exchange for a token

Exchange the code for an access token and call the VoiceInfra API, or use it as the credential for your MCP connection.

​
Using your app with MCP

If your client speaks MCP, you do not need to build any of the above by hand. Point it at the customer’s MCP address, choose OAuth, and the registration and approval flow happens for you. See MCP Server.

​
Design notes

  • Request the minimum. Broad read plus narrow write reads as trustworthy, and gets approved more often.
  • Group your permissions. Users see areas, not individual scopes. Asking for many permissions at once is normal, but they will be summarised into areas.
  • Handle denial. A user may allow some areas and not others, or refuse outright. Your app should degrade gracefully rather than assume full access.
  • Expect a per-workspace grant. A connection is scoped to one workspace. If a user wants your app in two workspaces, they connect twice.
To build a server-side app that connects to the VoiceInfra API, you need an OAuth client — which VoiceInfra creates for you on request. See OAuth for the API for what to send us and how the authorization flow works.

​
Frequently asked questions

Connected apps are outside apps using your VoiceInfra account, in the inbound direction. Integrations are the services your agents call out to, like your CRM or calendar. They are separate lists with separate permissions.
No. Disconnecting revokes the app’s access. Your agents, numbers, call logs, and settings are untouched.
Connected apps shows when each app was last used. Actions taken through the VoiceInfra API are subject to the same workspace scoping as everything else in the product.
Disconnect it. The app loses access immediately. If you did not approve it, change your password as well.
No. Nothing is shared until you approve a request, and you always choose the workspace on the approval screen.