Save a chosen call outcome from an IllyVoIP SDK dialer to Contacts

A custom SDK dialer can open an after-call form and save the agent’s selected business outcome to IllyVoIP Contacts. Your application must bind the call to an authorized contact, offer current status choices and preserve the contact’s other fields.

Start with the official IllyVoIP Webphone SDK 1.4.2 bundle and one managed phone owner. Your backend must authorize the signed-in user’s SIP identity and issue the short-lived browser token. The examples extend your application; they do not change the hosted Portal phone.

1. Bind the contact before calling

1. Resolve the customer record through your authenticated backend.
2. Retain the owned IllyVoIP contact ID or stable external identity separately from its display name.
3. Show the reviewed destination before starting the call.
4. Associate the returned SDK call ID with your application’s attempt reference and contact identity.

Do not change that association when the user selects another CRM row during the call. An SDK call ID is not automatically the public call-history ID. Use each identifier only with the service that issued it.

2. Open one form for the ended call

Observe call:ended on the owned SDK instance, read the event’s call identity and match it to your stored attempt. Deduplicate that transition locally and on the backend. An old event from a destroyed owner must not open a form for the new owner’s current contact.

Ask the agent to choose the actual business outcome. An answered SIP call does not establish “Interested,” and an unsuccessful attempt does not prove “Wrong number.” Include an honest no-outcome or cancel path rather than forcing the agent to invent a status.

3. Load the workspace and current contact

Request GET /api/v1/contacts/workspace from your backend and use the returned status and field configuration. Read the contact through the documented Contacts API and match its ID or external reference exactly. A search result is not a unique identity guarantee.

1. Refresh the allowed status choices when preparing the form.
2. Keep the selected contact and agent authorization fixed during save.
3. Retain the contact’s company, sharing, phone, email and configured custom fields.
4. If the current record differs from the version shown to the agent, compare the changes before proceeding.

4. Build a complete intended upsert

POST the complete intended contact to /api/v1/contacts, using the established identity and the chosen call_status. This endpoint is not a partial patch. Sending only an ID and status can clear omitted fields or replace them with defaults. Use the full field mapping in the Contacts API sync guide.

Apply a single-writer policy within your own integration and coordinate with human editors or other sync tools. The API does not promise a client-supplied compare-and-swap revision for this workflow. A fresh read reduces stale updates but does not eliminate a competing edit that occurs immediately afterward. If you cannot preserve another editor’s work confidently, stop for review.

5. Read back before closing the form

1. Disable repeat submission while the upsert is pending.
2. Check the HTTP and API result and retain the returned contact identity.
3. Compare the saved status and other important fields with the intended payload.
4. Mark the wrap-up saved only after that verification.
5. On an uncertain result, reread the same contact before retrying; retain the agent’s unsaved selection visibly.

This updates a Contact. It does not complete a campaign disposition, create a native call note or synchronize a separate CRM automatically. Implement those distinct operations only when their supported workflow is part of your design.

6. Test mismatches and competing work

Exercise duplicate ended events, a changed customer row, an unknown status, a deleted contact, an interrupted upsert and a human edit during wrap-up. Confirm you never write to a different contact or silently clear company and sharing values. Keep a minimal attempt/outcome audit without logging customer records or API credentials.

Related guides

• Sync CRM contacts into IllyVoIP with the Contacts API
• Use IllyVoIP calling inside your CRM
• Add mute, hold, resume and keypad controls to an IllyVoIP browser phone

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