Add IllyVoIP click-to-call buttons to customer records in your CRM

A custom CRM can use the IllyVoIP Webphone SDK to call the number on an authorized customer record. Resolve the current record, show the actual destination and submit one deliberate call through the existing phone owner. This is a customer-built integration, not a ready-made plugin for every CRM.

This guide targets the official Webphone SDK 1.4.2 browser distribution. Start with the installation guide, one managed phone owner and an authenticated backend that authorizes the user’s SIP identity. Keep permanent API keys and SIP passwords out of browser code.

1. Resolve the record through your backend

1. Authenticate the CRM user and check access to the selected customer record.
2. Return the permitted call number and a record revision or equivalent freshness reference.
3. Normalize the number with a known country context. Reject ambiguous or multiple-number input.
4. Show the customer label and complete destination together, allowing the user to cancel before calling.

Do not extract a number from arbitrary page text and assume it belongs to the selected record. Recheck access when issuing browser tokens too: disabling a button is not backend authorization. If the record changes while the confirmation is open, require a fresh review.

2. Use the existing ready owner

Wait for a connected, registered phone and no competing call before enabling this action. Keep microphone permission and audio controls visible. The example below accepts a destination already returned and confirmed by your authorized record workflow; it does not replace that workflow.

export function crmCaller(phone) {
  let submitting = false;
  let uncertain = false;
  return async function callConfirmed(number) {
    if (submitting || uncertain) throw new Error('Review the existing attempt');
    if (!/^\+[1-9][0-9]{6,14}$/.test(number)) throw new Error('Invalid number');
    const state = phone.getState();
    if (state.connected !== true || state.registered !== true || phone.getCalls().length) {
      throw new Error('Phone is not idle and ready');
    }
    submitting = true;
    try {
      return await phone.call(number);
    } catch (error) {
      uncertain = true;
      throw error;
    } finally {
      submitting = false;
    }
  };
}

Instantiate the helper once per owner, not once per click. On rejection it conservatively blocks another attempt for review. Your controller must reconcile the existing call state and failure before deliberately replacing that gate. Recreating the helper immediately in an error handler would defeat it.

3. Follow the returned call

1. Disable Call while submission is pending and display the exact destination being attempted.
2. Save the returned call ID with your application’s attempt reference.
3. Observe the actual call and terminal events. A returned call object is not proof of answer.
4. Bind End, Mute or Transfer to that selected call, not a stale customer row.
5. After completion, record the observed outcome and allow another deliberate action only when the owner is idle.

If the person changes CRM tabs or selects another record during a call, keep the active call panel associated with the original destination. Do not relabel the active conversation with whichever customer row happens to be selected now.

4. Add only appropriate CRM metadata

If you use the documented custom-header options, send only approved non-sensitive correlation values and follow the existing metadata guide. A header does not create CRM permissions, change caller-ID eligibility or automatically prove a disposition was saved in your CRM. Keep business updates in your own authorized backend.

5. Test the action’s failure cases

With a mocked phone and customer API, test denied record access, a changed number, double click, an existing call, rejected call creation and a lost response. Confirm none causes an automatic paid retry or a call to a stale destination. Then conduct one authorized end-to-end test, checking destination, caller ID, two-way audio and the CRM record actually saved.

For a production problem, retain the CRM attempt reference, SDK call ID when available, time and sanitized error. Keep tokens, SIP credentials and complete customer records out of browser logs and support screenshots.

Related guides

• Add browser calling with the Webphone SDK
• Use IllyVoIP calling inside your CRM
• Attach CRM reference metadata to Webphone SDK SIP requests
• Diagnose an IllyVoIP SDK call with preflight checks and WebRTC statistics

Reviewed 12 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.