Start with the supported package and reference
Open API documentation → Webphone SDK. Use Download web SDK bundle or the documented browser assets, and follow the matching release’s examples. Read any linked security advisory before integrating an older copy. This is a web/browser SDK, not a replacement for a native mobile calling integration.
Your developer should prepare an authenticated HTTPS application, an allowed SIP identity, microphone permissions and the current SDK’s required assets. The SDK Playground helps check the account and browser, but calls from it are real and can incur charges.
Keep permanent credentials on your backend
- Use the reference’s managed-token example as the normal production starting point.
- Your backend authenticates your application user and checks which IllyVoIP identity that user may use.
- The backend requests the documented short-lived browser authorization using the account API key. Return only the browser payload the SDK requires; do not return the permanent API key.
- Initialize the SDK using that payload and the matching current example. Handle expiry, logout and connection errors instead of repeatedly creating new sessions.
Do not accept an arbitrary identity from an unauthenticated browser or allow users to mint tokens for another account. Keep API keys and SIP passwords out of public JavaScript, repositories, page URLs and diagnostic screenshots. Raw SIP mode is an advanced alternative in the reference, not a reason to ship permanent account secrets in frontend code.
Make readiness visible to your users
Show connecting, ready, incoming, active, ended and failed states using the SDK’s documented events. Request microphone permission through a clear user action, allow audio-device selection where supported and handle permission denial visibly. A rendered keypad does not prove the phone registered; a registered phone does not prove two-way audio.
Do not assume the SDK supplies all of your application’s multi-device policy. Follow the current connection and disconnect lifecycle, and handle any session-conflict response visibly. A disconnected or ended session must stop presenting itself as the active phone. Clear account-specific phone state on logout and initialize the newly signed-in user’s authorized identity, not a cached identity from the previous user.
Run a small acceptance check
With permission, test one outgoing and one incoming call, answer/end, microphone and speaker audio, and any hold/keypad/transfer controls you expose. Test permission denial, lost connectivity, logout/account switching and your intended multi-device behavior. Follow current diagnostics and region guidance; region fallback is not a promise that an interrupted active call survives.
Use your own authorized test destinations, check rates and never treat repeated calls as free diagnostics. Do not collect or send recordings without the necessary notices and authorization.
Diagnose by stage
If authorization fails, inspect the backend response and user-to-identity permissions without logging secrets. If signaling fails, check the selected region and network/browser compatibility. If connected audio fails, check devices, microphone permission and network media access. Keep the SDK version, browser version, sanitized error, time/timezone and public call reference for Support.
The API reference remains authoritative for methods, payloads and token lifetimes. See API quick start for account access and safe request handling.