Many customers want their phone system to connect with a CRM, ticketing system, help desk, internal database, or custom application. Common goals include call logging, customer lookup, screen pop, click-to-call, routing calls based on customer data, or using AI to interact with callers.

Teklink provides and supports the phone service platform. Some integration capabilities are available through the platforms we resell, and Teklink can help explain those capabilities, point customers to available documentation, and provide platform-side information where applicable.

Custom CRM integrations, automation workflows, middleware, custom applications, AI applications, customer-hosted servers, browser extensions, WebRTC applications, and custom code are not services that Teklink normally builds, hosts, supports, troubleshoots, or maintains for customers.

These projects often depend on third-party systems, customer-specific APIs, business-specific logic, customer-owned infrastructure, and developer decisions outside of Teklink’s platform. Customers should plan to use their own developer, integration partner, CRM vendor, or internal technical resource for any custom integration work.

Teklink does not take responsibility for customer-built integrations, custom servers, external application behavior, API logic, webhook processing, data filtering, call-routing decisions made by external systems, or troubleshooting code that was not provided by Teklink.

This article is intended to explain available platform options and where each option fits technically. It is not a recommendation or implementation plan for a specific customer workflow.

Integration Types Covered in This Article

Phone system integrations may involve one or more of the following:

1. Out-of-the-box integrations
   Built-in or provider-supported CRM integrations.

2. Event subscriptions, hooks, or webhooks
   The platform sends call or system activity to an external URL or connected application.

3. Callflow-based triggers
   A call reaches a specific point in a route, and the system sends call data to an external URL.

4. Live call-routing integrations
   The phone system pauses during call handling and waits for an external server to respond with routing instructions.

5. API-based integrations
   External systems use platform APIs for actions such as click-to-call, call data lookup, user/device lookup, or configuration-related tasks.

6. Click-to-call / tel: link workflows
   Users click a phone number in a CRM, web page, or browser and start a call through a supported calling method.

7. WebRTC or custom softphone applications
   Customer-built browser or application-based calling experiences.

8. AI voice applications
   Customer-built applications that interact with callers using speech recognition, text-to-speech, AI services, and custom routing logic.

SkySwitch Integration Options

SkySwitch is built on the NetSapiens platform. Integration options can include provider-supported CRM integrations, NetSapiens event subscriptions, WebResponders, APIs, click-to-call options, and customer-built applications.

1. Out-of-the-Box Integrations

SkySwitch out-of-the-box CRM integrations are generally provided through the ReachUC Connector, built by Mondago.

These integrations may be useful when the customer uses one of the supported CRMs and only needs the features already supported by that connector.

For the current list of supported CRMs and the features available for each CRM, customers should review the integration list provided directly by the ReachUC Connector provider:

https://integrations.connector.reachuc.com/

Cost and enablement

SkySwitch out-of-the-box integrations may include additional costs, including:

• A monthly cost per enabled user seat

• Possible setup costs, depending on the integration and implementation requirements

Customers should contact Teklink for current pricing and to enable the integration for the required users.

Typical use cases

• CRM call logging

• Contact lookup

• Screen pop, where supported

• Click-to-call, where supported

• Basic call activity tracking inside the supported CRM

Limitations and considerations

• These integrations are limited to the CRMs and features supported by the ReachUC Connector.

• Feature availability can vary by CRM.

• Some CRMs may support call logging but not more advanced actions.

• Some CRMs may support click-to-call but not full call-flow automation.

• Custom workflows may not be possible through the standard connector.

• If the customer needs custom routing, custom ticket logic, AI handling, or integration with an unsupported application, another integration method may be needed.

• Any monthly seat cost and setup cost should be reviewed before enabling the integration.

2. Event Subscriptions / Webhooks

SkySwitch supports event-based integrations through the underlying NetSapiens platform. These are commonly referred to as event subscriptions or webhook-style integrations.

An event subscription is configured so that when a subscribed event occurs, the system sends data to a configured external URL.

This can be used when a customer wants to send phone-system activity to a CRM, ticketing system, reporting system, automation tool, or custom application.

Setup overview

Event subscriptions are configured through the API. The subscribed event type determines what kind of data is sent to the configured URL.

Because event subscriptions depend on the customer’s destination URL, testing process, and future changes, customers or their developers should plan to manage the event subscription configuration and webhook processing for their own integration.

NetSapiens API documentation is available here:

https://pbx.readme.io/reference/overview

Available event data types

The following event types may be available:

call

Sends active call updates.

This may produce a unique data set per terminated call ID and terminated device. A JSON field named remove with a value of yes may be added when the call is completed.

call_origid

Similar to call, but produces a unique entry per originating call ID.

This can generate less data in scenarios such as simultaneous ringing, multi-device ringing, and transfers.

subscriber

Sends updates to user/subscriber objects for the requested data.

presence

Similar to subscriber, but limited to presence and status message updates.

This may be available for more scopes than full subscriber updates.

auditlog

Streams changes from the audit log, including adds, updates, and deletes for objects.

agent

Sends updates when call center agent status changes.

call_recording

Sends an update when a call recording is available. The event posts to the configured URL and includes a URL where the recording can be accessed.

cdr

Sends an update when a CDR is added or updated.

Common use cases

• Log inbound calls in a CRM

• Log outbound calls in a CRM

• Create tickets for missed calls

• Add call notes to existing tickets

• Trigger automation when a CDR is created

• Retrieve call recording links when recordings become available

• Track call center agent status changes

• Sync user or presence information into another system

• Feed call activity into a custom dashboard

Important limitation: duplicate or multiple events per call

Event subscriptions may trigger multiple times for what a user considers one call.

For example:

• A call ringing multiple endpoints may create multiple event updates.

• A simultaneous-ring scenario may produce more than one related update.

• A transferred call may create additional call events.

• Different event types may represent the call from different perspectives.

• Some events may update during the call, while others may post after the call is completed.

Customers or their developers must decide which events they want to process and how they want to identify, merge, deduplicate, or ignore duplicate updates.

Teklink may not have enough information to determine the customer’s exact desired filtering logic. The customer’s CRM or middleware should be designed to decide what should count as the final call log, what should be ignored, and what should update an existing record.

Limitations and considerations

• Event subscriptions are usually used for logging, status updates, reporting, or triggering external workflows.

• They may not be enough when the customer wants to control live call routing.

• The customer must provide a reliable external URL that can receive the event data.

• The customer or their developer must understand the event payloads and build the logic to process them.

• Deduplication and filtering are the customer’s responsibility.

• Teklink can help explain available options and provide direction, but custom CRM logic, webhook processing, event subscription management, and endpoint hosting are not normally part of standard support.

3. Live Call Routing with WebResponder

SkySwitch can support live call routing logic through WebResponders.

WebResponders are configured through the API, similar to event subscriptions. When a call is routed to a WebResponder, the system posts call information to the configured server and waits for a response before continuing the call.

This allows a customer-controlled server to make routing decisions based on information from a CRM, ticketing system, database, or custom application.

SkySwitch documentation is available here:

https://docs.skyswitch.com/en/articles/1096

Additional NetSapiens documentation is available here:

https://docs.ns-api.com/v44.3/docs/web-responders-v2

The NetSapiens documentation may include information for a later NetSapiens version than the version currently used by Teklink/SkySwitch, so not every item in that documentation may apply.

WebResponder response types

A WebResponder response can generally return one of the following actions:

Forward

Transfers the call to the extension configured in the XML response.

Gather

Collects DTMF input from the caller and posts the collected input to the URL configured in the XML response.

A Gather response may also include a media file to play before or while collecting input.

Play

Plays a media file hosted on the customer’s server. The response includes the URL for the media file, and the phone system downloads and plays that file to the caller.

Common use cases

• Route callers based on CRM or ticket status

• Route a caller to the owner of an existing case

• Send callers to a specific extension, department, or queue

• Collect caller input before deciding the next step

• Play a customer-hosted message before continuing the call

• Use an external system to decide how the call should proceed

Important reliability considerations

WebResponders must be handled carefully because they are part of the live call path.

If the customer’s server responds with invalid data, the call may disconnect. If the XML response is invalid, incomplete, or not formatted correctly, the call may disconnect. If a media file is invalid, unsupported, too large, or takes too long to download, the caller may experience dead air or the call may disconnect.

Media files should be kept as small as reasonably possible. Larger files take longer for the system to download, and the caller may be waiting on the line while that download happens.

Limitations and considerations

• WebResponders require a reliable customer-owned server or middleware endpoint.

• The endpoint must respond quickly and correctly during the live call.

• The customer is responsible for CRM/API logic, authentication, response formatting, media file hosting, uptime, and error handling.

• Invalid responses can affect live calls.

• WebResponders are more complex than basic webhook/event logging.

• Teklink can help explain the phone-system side, but the business logic and server implementation are custom development and are not normally supported, hosted, or maintained by Teklink.

4. API Options

SkySwitch APIs are available for supported integration use cases.

Available API documentation can be found here:

https://portal.theteklink.net/ns-api/webroot/apidoc/

For specific help with API access or API usage, customers should contact Teklink support for guidance.

To request API credentials, customers should reach out to the Teklink support team. API access should be requested by the account admin. If the request is not made by the account admin, Teklink may require admin approval before API access can be provided.

Possible API use cases

• Click-to-call from a CRM

• Looking up users, extensions, or devices

• Pulling call history

• Updating certain configuration items, if permitted

• Building reporting or dashboard integrations

• Connecting an external application to phone-system data

Limitations and considerations

• API access may require approval.

• API access should be requested by the account admin.

• API capabilities depend on what the platform exposes.

• API usage should be reviewed for security and rate limits.

• Customers are responsible for the external application using the API.

• Teklink does not normally build, host, troubleshoot, or maintain the customer’s API connector.

Kazoo / Dimensions Integration Options

Kazoo is the underlying phone platform. Teklink also provides access to an integration layer on top of Kazoo, known as Dimensions, which interacts with Kazoo and includes additional integration options.

Because of this, Kazoo integration options may include direct Kazoo capabilities as well as Dimensions-based capabilities.

1. Out-of-the-Box Integrations

Kazoo directly does not currently provide the same type of standard out-of-the-box CRM integration list as some other platforms. However, Dimensions provides a limited set of out-of-the-box CRM integrations.

The current Dimensions CRM integration documentation can be found here:

https://docs.theteklink.cloud/crm/en-us/

Customers should review the Dimensions documentation directly for the current list of supported CRMs and supported features, since the available integrations may change over time.

How Dimensions CRM integrations work

Dimensions CRM integrations are generally client-side integrations. This means the end user may need to be logged in to both the CRM and the Dimensions extension or related client-side integration for the call activity to be logged or presented correctly.

Typical use cases

• CRM call logging

• Contact lookup

• Screen pop, where supported

• Manual or automatic call logging, depending on the CRM and integration settings

• Basic user-level CRM interaction from the Dimensions integration

Limitations and considerations

• The end user may need to be logged in to both the CRM and the Dimensions extension or client-side integration.

• Call logging may depend on when the call rings, is answered, or is manually logged.

• Calls that do not ring to that user may not be logged by that user’s client-side integration.

• If logging is configured when a call rings, calls that ring to more than one user may create duplicate records.

• Feature availability depends on the CRM and the supported Dimensions integration.

• These integrations may not support custom business logic, advanced routing, or unsupported CRMs.

2. Dimensions Softphone, tel: Links, and Screen Pop Options

Teklink also provides softphone access through Dimensions. In some cases, this may be enough for customers that do not need a full CRM integration but still want easier calling or basic customer lookup behavior.

Dimensions softphone options can support tel: links and may also be used in companion mode, depending on the customer’s setup.

Dimensions can also support screen popping to a URL or executable file when that URL or application can accept one of the configurable variables from the call details.

Common use cases

• Click a phone number using a tel: link

• Use the Dimensions softphone as the default calling application

• Use companion mode with a desk phone or other endpoint

• Open a customer record lookup URL when a call arrives

• Launch an internal application or executable using call variables

• Provide a lighter-weight option when a full CRM integration is not available or not needed

Limitations and considerations

• This is not the same as a full CRM integration.

• The customer’s CRM or application must support a URL, executable, or lookup format that can use the available call variables.

• Screen pop behavior depends on the user’s device, application settings, and the external system being opened.

• This may help with customer lookup, but it may not automatically create or update CRM records unless the external system supports that workflow.

3. Call Logging and Event Options

Kazoo and Dimensions provide several ways to send call-related or event-related information to an external system. These options are not all the same, and the available option depends on whether the customer needs general event updates, callflow-based triggers, live call routing, or a single post-call record.

The main options are:

• Kazoo event-driven webhooks

• Kazoo WebSocket subscriptions

• Kazoo Callflow Webhook module

• Kazoo PIVOT

• Dimensions post-call webhooks

3A. Kazoo Event-Driven Webhooks

Kazoo event-driven webhooks are triggered by actions that happen on the server. When the configured event occurs, Kazoo sends an HTTP request to the configured URL.

These events can cover a wide range of server activity, including call-related events.

More details are available in the Kazoo documentation:

https://docs.2600hz.com/events/webhooks/webhooks-event-driven-http/

Setup

Event-driven webhooks are configured in the Kazoo portal using the Webhooks app.

Customers can generally configure these themselves in the portal. If the Webhooks app is not available on the account, the customer can contact Teklink support to request access to the app.

Common use cases

• Send call-related events to an external system

• Trigger an automation when a selected Kazoo event occurs

• Send server-side activity to a CRM, ticketing system, reporting tool, or middleware endpoint

• Build custom workflows based on Kazoo events

Limitations and considerations

• Event-driven webhooks may trigger multiple times for what the customer considers one call.

• The customer or their developer must determine which events matter for their workflow.

• The customer’s external system may need to filter, merge, or ignore repeated call-related events.

• Teklink may not have enough information to determine the customer’s exact filtering or deduplication logic for their CRM or application.

• These webhooks are useful for event-based processing, but they may not always be the simplest option for a single clean call log.

3B. Kazoo WebSocket Subscriptions

Kazoo also supports WebSocket-based event subscriptions.

This option is similar in concept to webhooks because customers can subscribe to certain events, but the delivery method is different. Instead of Kazoo sending HTTP requests to a webhook URL, the customer’s application opens a WebSocket connection and receives event data over that live connection.

More details are available in the Kazoo documentation:

https://docs.2600hz.com/events/websockets/blackhole-web-socket-server/

Setup

Customers who want to test or review WebSocket event data can request access to the WebSockets app in the portal through Teklink support.

Common use cases

• Web applications that need live event updates

• Real-time dashboards

• Agent or user-facing applications

• Testing and reviewing what Kazoo event data looks like

• Custom applications that maintain an active connection to Kazoo events

Limitations and considerations

• WebSocket subscriptions require an application that can maintain a live socket connection.

• This is most commonly useful for web applications or real-time applications.

• This is different from a simple server-side HTTP webhook workflow.

• The customer or their developer is responsible for handling the WebSocket connection, reconnection logic, filtering, and event processing.

3C. Kazoo Callflow Webhook Module

The Kazoo Callflow Webhook module is an HTTP trigger that is placed directly inside a callflow.

Unlike event-driven webhooks, this is not triggered simply because a general event happened on the server. Instead, it triggers when a call reaches that specific webhook step in the callflow.

Callflow webhook documentation is available here:

https://docs.2600hz.com/call-control/callflow/callflow-actions/webhook/

How it works

The webhook module can be placed anywhere in a callflow, such as:

• Right when an inbound call comes in

• After a menu option is pressed

• Before sending the call to a user, device, group, or queue

• At another point in the inbound call route

When the call passes that step, Kazoo posts the call data to the configured URL and then continues the callflow without waiting for the customer’s server to respond.

The webhook module can be configured by the customer in the Callflows app where available, or by Teklink as part of normal callflow configuration assistance.

Common use cases

• Notify an external system when an inbound call reaches a specific route

• Send call data to a CRM or ticketing system at a specific point in the callflow

• Trigger a workflow only when a particular menu option or route is used

• Send cleaner callflow-specific notifications instead of listening to all call events

Limitations and considerations

• Callflow webhooks are mainly tied to call routing logic.

• Since callflows are generally used for inbound call routing, this may not be ideal if the customer also needs outbound call notifications.

• There may be workarounds for other scenarios, but the customer’s desired workflow should be reviewed carefully.

• The webhook posts data and continues the call; it does not wait for the external server to tell Kazoo what to do next.

• If the customer needs the external server to control the next call action, PIVOT is the Kazoo option designed for dynamic callflow control.

3D. Dimensions Post-Call Webhooks

Dimensions provides a post-call webhook option that can be useful when the customer wants a cleaner single call-level trigger after the call is completed.

Documentation is available here:

https://docs.theteklink.cloud/en-us/config/integration/webhooks/

How it works

Unlike some Kazoo event or callflow options, the Dimensions post-call webhook can be configured to determine which calls should trigger, such as inbound or outbound calls.

The webhook posts once the call is fully completed, including all call legs.

Common use cases

• Log completed calls into a CRM or ticketing system

• Post a single call summary after the call ends

• Include Dimensions call tags in the external workflow

• Link to the Dimensions call session view

• Provide access to the call recording link through the call session view, if call recording is enabled

• Combine with other hook options when both live updates and post-call summaries are needed

Limitations and considerations

• The trigger happens only after all legs of the call are completed.

• This is not ideal if the customer needs to log or act on the call before the call ends.

• This may be a better fit when the customer wants a single post-call record instead of multiple live call events.

• This is an add-on option and may have a monthly fee.

• Setup requires assistance from the support team.

• Customers should contact Teklink support for setup details, availability, and cost.

4. Live Call Routing with PIVOT

Kazoo supports advanced live call routing using PIVOT.

PIVOT is similar to the Callflow Webhook module in that it is triggered at a specific point in a callflow. The major difference is that PIVOT waits for the customer’s server to respond with instructions for how the call should continue.

This allows the customer’s server to dynamically control the next step of the call based on CRM data, ticket status, database lookups, business rules, or other custom logic.

PIVOT documentation is available here:

https://docs.2600hz.com/developers/pivot/pivot-programmable-flows/

Kazoo callflow and callflow module documentation is available here:

https://docs.2600hz.com/call-control/callflow/pbx-with-callflows/

How Kazoo callflows work

Kazoo routes are called callflows.

A callflow is a JSON-based route that tells Kazoo what action to take. A callflow generally includes:

• A module, which tells Kazoo what type of action to perform

• data, which contains the details for that action

• children, which define the next steps in the route

Children can be a default next action, or they can be based on rules. For example, a menu module may use digits as children so Kazoo knows which action to take based on the caller’s menu selection.

Normally, callflows are configured statically and saved on the Kazoo platform. With PIVOT, the customer’s server can return a dynamic callflow JSON response instead.

How PIVOT works

When a call reaches the PIVOT step, Kazoo sends call information to the configured URL and waits for the customer’s server to respond.

The customer’s server must respond with a valid Kazoo callflow JSON structure. Kazoo then uses that response to continue routing the call.

For example, if the customer’s logic decides to route the caller to a specific user, the response may use the user module and include the backend user ID in the data section.

Important ID requirements

Many Kazoo callflow modules reference objects by backend ID.

For example, routing to a user, device, menu, or media file may require the correct Kazoo backend ID for that object.

Because of this, the customer’s PIVOT server may need to either:

• Store the relevant Kazoo object IDs in the customer’s application, or

• Fetch the required IDs from Kazoo through the API when needed

If media is required and the customer is not using a text-to-speech style module, the media file may also need to exist in Kazoo and be referenced correctly.

Common use cases

• Search a CRM by caller ID before routing

• Create or update a ticket before the call reaches an agent

• Route the caller to the assigned ticket owner

• Route based on customer status or account type

• Add call context before the call continues

• Use customer-specific logic to decide the next callflow action

• Route calls differently after checking an external database

• Build dynamic routing flows that are not fully static in the Kazoo portal

Important reliability considerations

PIVOT must be handled carefully because it is part of the live call path.

If the customer’s server does not respond correctly, or if the response is not valid Kazoo callflow JSON, the call may disconnect.

The customer’s server must respond quickly and reliably, and the response must use valid modules, valid data, and valid object IDs.

Limitations and considerations

• PIVOT requires a customer-owned or customer-provided external server.

• The server must respond quickly and reliably during the live call.

• The response must be valid Kazoo callflow JSON.

• The customer is responsible for CRM/API access, authentication, business logic, Kazoo object IDs, uptime, and failures.

• Incorrect responses, invalid IDs, or server downtime can affect live calls.

• Teklink can help explain how PIVOT works and may provide available documentation, but Teklink does not normally write, host, troubleshoot, or maintain the customer’s PIVOT application.

5. API Options

Kazoo provides REST APIs that can be used for supported integration use cases.

The Kazoo API is structured around account-level resources and uses an authentication token. In general, an application authenticates by sending a request using valid credentials or an API key, receives an auth token, and then uses that token for additional API requests.

Kazoo REST API documentation is available here:

https://docs.2600hz.com/developers/rest/introduction/

Possible API use cases

• Click-to-call

• User, device, number, and account data lookup

• Callflow lookup or management

• Call history or CDR lookup

• Custom reporting

• Provisioning workflows

• CRM-side actions that interact with the phone system

Limitations and considerations

• API access may require approval and proper credentials.

• API credentials and auth tokens must be handled securely.

• API usage should be reviewed for least-privilege access.

• Customers must maintain any external application or middleware that uses the API.

• Teklink can help identify the relevant API documentation where available, but custom development is outside standard support.

6. Click-to-Call Options

Kazoo can support click-to-call style workflows through supported APIs or applications.

The native tel: calling format may also work if the customer has a compatible softphone installed on their PC and registered as the default calling application, or if they use a compatible companion calling application.

If the customer wants to initiate calls from a server-side integration, Kazoo provides API-based options.

6A. Quick Call

Quick Call can be triggered on a user or device and can initiate the call directly as if it was placed from that user or device.

Quick Call documentation is available here:

https://docs.2600hz.com/developers/rest/call-control/advanced-features/quickcall/

Common use cases

• CRM button starts a call from the user’s device

• Internal application starts a call from a specific user or device

• Server-side application initiates an outbound call using authenticated API access

Limitations and considerations

• Quick Call requires authentication.

• The external system must have a secure way to authenticate and make the API request.

• This is usually a better fit when the customer has an authentication flow or server-side middleware that can safely use API credentials.

6B. Click to Call

Kazoo Click to Call uses a preconfigured Click to Call ID. When that Click to Call endpoint is triggered, Kazoo initiates a call to the configured extension number.

Click to Call documentation is available here:

https://docs.2600hz.com/developers/rest/usage/click-to-call/

The configured destination uses the extension number, not only a backend object ID. This means it can also be configured to reach a callflow, depending on the customer’s setup.

Click to Call can be configured to call the extension first or the contact first. It can also be configured to require authentication or to work without authentication, depending on the desired setup.

Common use cases

• CRM button triggers a preconfigured call flow

• External application starts a call using a configured Click to Call endpoint

• Customer wants a simpler trigger URL or flow after the Click to Call endpoint is already configured

Limitations and considerations

• Click to Call must be preconfigured.

• If the configured extension does not exist, is changed, or has a typo, the call may not work as expected.

• Since the call is initiated by the server, call logs may not appear the same as a normal outbound call placed directly from the user’s device. In some cases, it may appear more like an inbound/server-originated call rather than a standard user outbound call.

Shared Options and Considerations

The following options and considerations can apply to both SkySwitch and Kazoo, depending on the customer’s platform, endpoint setup, available permissions, and technical requirements.

1. Click-to-Call and tel: Links

Some CRMs and applications support clickable phone numbers using the standard tel: format.

This can work when the user’s computer has a compatible softphone or companion application installed and registered as the default calling application.

Other click-to-call workflows may use a platform API, CRM custom button, middleware endpoint, or browser extension.

Limitations and considerations

• The CRM or application must support clickable phone numbers, custom buttons, workflows, external calling links, or tel: links.

• Some systems only support tel: links and cannot call a custom API directly.

• Browser extensions require deployment and maintenance.

• Desktop behavior can vary by operating system, browser, user permissions, and installed calling applications.

• API-based click-to-call may require middleware to keep credentials secure.

• Customer-created click-to-call workflows are not normally built, hosted, supported, or maintained by Teklink.

2. WebRTC Applications

For customers that need more control over the calling experience, a WebRTC-based application may be an option.

Teklink provides access to supported softphone options for PC/browser calling. If a customer wants to integrate a softphone directly into their own web application instead, Teklink can provide SIP registration information where applicable, such as SIP credentials, server information, and required ports.

However, a customer-built WebRTC application is not provided or supported by Teklink. Teklink would not normally be able to troubleshoot the customer’s application, browser code, server code, or custom WebRTC implementation.

Common use cases

• Embed calling inside a CRM or help desk

• Build a custom agent calling screen

• Display customer information beside the call

• Add custom call controls

• Build specialized call workflows

• Integrate with internal applications more deeply than a standard softphone

Limitations and considerations

• WebRTC applications require custom development.

• The customer must host and maintain the application.

• Authentication, security, browser compatibility, audio handling, and call reliability must be planned carefully.

• Teklink can provide SIP registration information where applicable, but a custom WebRTC app is outside standard support.

• Teklink does not normally troubleshoot customer-built WebRTC applications.

3. AI Voice and Advanced Calling Applications

A WebRTC, SIP-based, or server-side voice application can also be expanded to support AI-assisted call handling.

In this type of design, the customer or their developer builds an application that registers to the phone system similarly to a user or device, answers or handles the call, listens to the caller, interacts with an AI system, checks a knowledge base, and then takes action.

For example, a customer may build a Node.js server with a WebRTC or SIP-based application that handles the call server-side as if it were a live user, then transfers the call to the relevant party when needed.

Teklink can provide the general concept and SIP registration information where applicable, but Teklink does not provide, build, host, support, or troubleshoot the customer’s AI voice application.

Possible use cases

• AI receptionist

• Call triage

• Answering common questions from a knowledge base

• Collecting customer details before transferring

• Routing callers to the correct department

• Creating tickets automatically

• Summarizing calls

• Assisting agents during live calls

Limitations and considerations

• This is a custom application project.

• It may require speech-to-text, text-to-speech, AI model integration, knowledge base integration, and call control logic.

• The customer must consider privacy, consent, call recording laws, data security, and reliability.

• Teklink does not build, host, support, troubleshoot, or maintain this type of application.

4. Customer Responsibility for Custom Integrations

For any custom integration, the customer should be prepared to provide or arrange the following:

• A developer or integration partner

• A server or hosting environment, if needed

• API access to their CRM, ticketing system, or custom application

• Security and authentication design

• Ongoing maintenance

• Error handling and monitoring

• Testing before production use

• Compliance review where required

Teklink can help clarify phone-platform capabilities and point customers toward available documentation, but custom integration ownership remains with the customer or their developer.

Teklink does not normally build, host, support, troubleshoot, or maintain custom customer integrations, customer-owned servers, custom webhook processors, browser extensions, WebRTC applications, AI voice applications, or middleware that connects to outside systems.

Need help with a custom integration?

For customers who need assistance building a custom phone system integration with their CRM, ticketing system, or internal application, we can recommend Amtech Consulting.

They have experience working on phone system integrations and have been thorough and professional throughout the integration process.

Contact: Amtech Consulting
Email: info@amtechcg.com

Documentation Links

SkySwitch / NetSapiens

• ReachUC Connector integrations: https://integrations.connector.reachuc.com/

• NetSapiens API overview: https://pbx.readme.io/reference/overview

• SkySwitch WebResponder article: https://docs.skyswitch.com/en/articles/1096

• NetSapiens WebResponders v2 documentation: https://docs.ns-api.com/v44.3/docs/web-responders-v2

• SkySwitch API documentation: https://portal.theteklink.net/ns-api/webroot/apidoc/

Kazoo / Dimensions

• Dimensions CRM integrations: https://docs.theteklink.cloud/crm/en-us/

• Kazoo event-driven webhooks: https://docs.2600hz.com/events/webhooks/webhooks-event-driven-http/

• Kazoo WebSocket / Blackhole server: https://docs.2600hz.com/events/websockets/blackhole-web-socket-server/

• Kazoo Callflow Webhook module: https://docs.2600hz.com/call-control/callflow/callflow-actions/webhook/

• Dimensions post-call webhooks: https://docs.theteklink.cloud/en-us/config/integration/webhooks/

• Kazoo PIVOT: https://docs.2600hz.com/developers/pivot/pivot-programmable-flows/

• Kazoo callflows and callflow modules: https://docs.2600hz.com/call-control/callflow/pbx-with-callflows/

• Kazoo REST API introduction: https://docs.2600hz.com/developers/rest/introduction/

• Kazoo Quick Call: https://docs.2600hz.com/developers/rest/call-control/advanced-features/quickcall/

• Kazoo Click to Call: https://docs.2600hz.com/developers/rest/usage/click-to-call/