For years, softphones have followed a familiar pattern.

You build a branded communications app. Users make calls, send messages, check contacts, and manage their accounts. Whenever you want to add a new capability, a CRM integration, a support dashboard, a patient portal, or a dispatch console, you face the same challenge:

Build it natively for Android. Build it natively for iOS. Submit app updates. Wait for users to upgrade.

Repeat.

This approach works, but it is expensive, slow, and difficult to scale.

What if your softphone could become a platform instead?

That is exactly what the Acrobits IPC SDK enables.

And it does this in the open. The IPC SDK turns Cloud Softphone into a framework you extend on your own terms: bring any web tool, from any vendor, and ship it without waiting on anyone's roadmap.

What the IPC SDK is

Cloud Softphone has always been a modular platform. Beyond calling and messaging, it can host custom web content directly inside the app, the same mechanism CSPs already use for promotions, usage dashboards, and support pages. Historically that web content has been passive: a web view that displays a page but cannot talk to the native layer around it.

The IPC SDK changes that. It is a published TypeScript package (@acrobits/ipc-sdk) that lets a web application running inside the Cloud Softphone WebView communicate directly with the native app through a secure inter-process communication layer.

In practical terms, it lets a web application leverage native Cloud Softphone functionality such as:

• SIP calling
• Contacts and contact matching
• Call state information
• Push notification registration
• Native badge counts
• Application lifecycle events

while keeping all business logic inside a web-based application.

The result is a hybrid architecture that combines the flexibility of web development with the reliability of the native communications infrastructure that already powers Cloud Softphone deployments across iOS, Android, Windows, and macOS.

Where it fits: from web tab to interactive module

It helps to place the IPC SDK inside the Cloud Softphone module model rather than treating it as a standalone feature.

Cloud Softphone is assembled from modules/features. A provider chooses calling, messaging, contacts, presence, file transfer, and custom web tabs, then brands and ships the result. Web tabs were always part of that toolkit, but for some time they were one-directional.

The IPC SDK upgrades the web tab from a display surface into a first-class, interactive module. The same web content that used to show a billing page can now initiate calls, react to incoming calls, and read native contact data, without leaving the app and without the provider shipping a new native build.

In other words, the IPC SDK is not a new product bolted onto Cloud Softphone. It is what turns an existing module into a development platform.

The IPC SDK architecture at a glance

The native app remains the system of record for telephony. The web module owns the business logic and UI. The IPC SDK is the contract between them.

The web module typically also talks to your own backend or a third-party API (a CRM, a ticketing system, a patient directory). The IPC bridge handles everything that has to touch the device's communications layer; your backend handles everything else.

How to implement the IPC SDK

Not a developer? The next few sections show your engineers the actual code, so you don't need to follow every line. The takeaway: adding these features is ordinary web development, handled by a web team using tools they already know. For the business view of what this unlocks, skip ahead to Turn Cloud Softphone into a communications workspace.

The SDK is distributed on npm and ships with TypeScript types, so method signatures and payloads are discoverable in your editor.

# pnpm (recommended)
pnpm add @acrobits/ipc-sdk

# or
npm install @acrobits/ipc-sdk

The lifecycle of a module is straightforward: detect that you are running inside a Cloud Softphone host, register your listeners, then open the connection.

import { IPCManager } from '@acrobits/ipc-sdk';

const manager = new IPCManager();

// 1. Confirm we are running inside the native host.
//    In a normal browser this returns something other than 'host',
//    so the same build can run standalone for development.
if ((await manager.determineContext()) !== 'host') {
  // Standalone mode, or context could not be determined.
  // Fall back to a browser-only experience.
  return;
}

// 2. Register listeners before connecting.
manager.onBadgeQueryRequest(() => {
  const count = getUnreadCount();
  manager.badgeUpdate(count);
});

manager.onLifecycleEvent((eventName, payload) => {
  // React to foreground / background / resume events, etc.
  handleLifecycle(eventName, payload);
});

// 3. Open the bridge.
await manager.initiateConnection();

Two patterns do most of the work in business integrations.

Contact matching lets the web module resolve a SIP URI or phone number against the user's native contacts, which is what powers a caller screen-pop:

const matches = await manager.matchContacts([
  { type: 'uri', cloudId: 'MY_CLOUD_ID', uri: 'tel:+1234567890' },
  { type: 'cloudUsername', cloudId: 'MY_CLOUD_ID', cloudUsername: 'jdoe' }
]);

for (const contact of matches) {
  console.log(contact.displayName, contact.uri, contact.profilePictureUrl);
}

Calling lets the web module ask the native app to place a SIP call. The web app never implements SIP itself; it hands the number to Cloud Softphone and the native stack does the rest. Refer to the IPCManager call methods and the IPCEvents enum in the SDK reference for the exact signatures and the call-state events you can subscribe to.

A note on standalone mode: because determineContext() distinguishes host from browser, you can develop and demo the same web build in a normal browser, then drop it into Cloud Softphone unchanged. That is useful for both engineering velocity and presales demos.

Worked example: a HubSpot integration

To make this concrete, here is how a HubSpot module would behave inside Cloud Softphone. The goal: agents see who is calling with full CRM context, can click to call from a record, and have the call logged automatically.

Inbound call, screen-pop with CRM context:

// When a call comes in, the native layer surfaces the remote number.
// Resolve it against native contacts, then enrich from HubSpot.
async function onIncomingNumber(number) {
  const [native] = await manager.matchContacts([
    { type: 'uri', cloudId: CLOUD_ID, uri: `tel:${number}` }
  ]);

  const hubspot = await fetch(
    `/api/hubspot/lookup?phone=${encodeURIComponent(number)}`
  ).then(r => r.json());

  renderScreenPop({
    name: native?.displayName ?? hubspot.name,
    company: hubspot.company,
    lastDeal: hubspot.lastDeal,
    openTickets: hubspot.openTickets,
    avatar: native?.profilePictureUrl
  });
}

Click-to-call from a HubSpot record:

// Agent clicks "Call" on a HubSpot contact card in the web module.
function callFromRecord(contact) {
  // Hand the number to Cloud Softphone's native SIP stack.
  // (See IPCManager call methods in the SDK reference.)
  manager.placeCall(`sip:${contact.phone}@${SIP_DOMAIN}`);
}

Automatic logging when the call ends:

// Subscribe to call-state events and write the result back to HubSpot.
manager.onLifecycleEvent(async (eventName, payload) => {
  if (eventName === 'callEnded') {
    await fetch('/api/hubspot/log', {
      method: 'POST',
      body: JSON.stringify({
        contactId: payload.contactId,
        durationSec: payload.duration,
        direction: payload.direction,
        timestamp: Date.now()
      })
    });
  }
});

The result is a HubSpot experience that lives inside the same app the agent already uses to talk to customers. No native build, no app store cycle, no separate dialer. The exact event names and payload fields are listed in the SDK reference; the shape above shows the integration pattern.

Build once, deploy everywhere

Traditional telecom feature development repeats the same native cycle for every feature. The IPC SDK collapses it into a single web build:

The web application runs inside Cloud Softphone while the native app continues handling telephony, push notifications, audio routing, and platform-specific behavior. This significantly reduces development effort while maintaining a native user experience.

Native-only vs. web module: a side-by-side

The point is not that web modules replace native development. Deep device capabilities still belong in the native layer, which is exactly why the IPC SDK leaves telephony there. The point is that business logic no longer has to ride the native release cycle.

Turn Cloud Softphone into a communications workspace

The most interesting use cases are not telephony features. They are business applications. The IPC SDK makes it possible to embed specialized workflows directly inside your communications app.

Whatever your team builds, whatever your vendors offer, and whatever a partner brings can live inside the same branded app, and the framework stays agnostic about who made it.

CRM integration

Allow users to:

• Search customers
• Open account records
• Review interaction history
• Launch calls with a single click

without leaving the softphone.

Help desk and customer support

Support agents can:

• View tickets
• Access customer profiles
• Update case notes
• Start outbound calls

from a single interface.

Healthcare applications

Healthcare providers can integrate:

• Patient directories
• Appointment schedules
• Telehealth workflows
• Internal staff directories

directly inside the communications application.

Dispatch and logistics

For transportation and field-service organizations, embedded applications can provide:

• Driver status
• Route information
• Dispatch queues
• Customer communication tools

while still leveraging Cloud Softphone's native calling capabilities.

Team messaging

Embed a messaging workspace that shares the softphone's identity and contacts:

• Persistent team and customer chat
• Escalate any thread to a call with one tap
• Shared contact matching, so names and avatars line up with the dialer
• Native push for new messages

without running a separate messaging app.

Video conferencing

Drop a video room into the same app your users already call from:

• Start or join a meeting from a contact or CRM record
• Escalate a live voice call to video
• Bring your own provider or a vertical video service
• One identity across voice, messaging, and video

no second app and no separate login.

Native calling from web applications

One of the most powerful IPC SDK capabilities is click-to-call integration. Web modules can initiate SIP calls through the native application.

This enables scenarios such as:

• Calling directly from CRM records
• Escalating chats to voice calls
• Launching calls from support tickets
• Calling contacts from custom directories

The web application does not need to implement SIP functionality itself. Cloud Softphone handles the communications layer.

Real-time call awareness

Modern business applications need context. The IPC SDK allows web modules to access active call information and receive call-state updates.

This creates opportunities for:

• Supervisor dashboards
• Agent status panels
• Call monitoring interfaces
• Workforce management tools
• Real-time CRM synchronization

Leverage native contacts

The SDK also exposes Cloud Softphone's contacts, including selection and matching. As shown in the HubSpot example, a single matchContacts call resolves SIP URIs or phone numbers against the user's native contacts and returns display names, labels, and profile pictures.

This allows developers to build:

• Corporate directories
• Team collaboration tools
• Messaging applications
• Presence-enabled contact lists

without maintaining separate contact databases.

Push notifications without reinventing the wheel

The IPC SDK exposes push token information to embedded web applications, making it possible to:

• Register devices with backend services
• Synchronize notification subscriptions
• Connect messaging platforms
• Maintain user-device relationships

without building a separate mobile notification framework.

The strategic shift: from product to open framework

Traditionally, softphones are finished products: you take the features the vendor shipped, on the vendor's roadmap. With embedded web applications, Cloud Softphone becomes an open framework instead. We do the hard part of the phone, calling, push, audio, and contacts, and you decide what runs inside it.

Providers can continuously introduce new functionality without:

• Major mobile development projects
• Frequent app-store releases
• Platform-specific feature implementations

Instead, they can extend the application through web-based modules that leverage existing communications infrastructure.

What this means for service providers

Potential opportunities include:

• Premium CRM integrations
• Vertical-industry solutions
• Contact-center enhancements
• Enterprise collaboration tools
• Workforce management modules
• Industry-specific workflow applications

Each extension increases the value of the communications platform while reducing development complexity.

And every web tab is a revenue surface, not just a feature. Because tabs switch on per user and per tenant, each one is a value-added service you can package and price: a premium CRM bundle for one client, a video room for another, compliance archiving for a third. You spin it up on the fly, and it bills inside the app your subscribers already pay for.

Beyond the softphone

The IPC SDK adds the layer that makes it a framework: open extensibility. You are not locked into a fixed feature set or someone else's release schedule; you bring whatever your business runs on and ship it on your own timeline.

Instead of asking, "What features should our softphone have?"

Providers can start asking:

"Which business applications should live inside our communications platform?"