The salesperson clicks your existing Call button and speaks through their
headset. Trackly handles the browser media connection and telephone call. This
requires adapting your calling code; the SDK is not a Twilio-compatible drop-in.
Browser calling requires activation for your Trackly account. Complete your
account’s calling setup and confirm activation with Trackly before testing.
A downloaded SDK or an API key alone does not enable live calls.
Before you start
Trackly supplies or confirms:- Your account and a server-held API key with
voice_calls.readandvoice_calls.write. - Your voice-enabled caller number, approved media origins, call/session limits, and an API quota sized for your active agents.
- The account’s calling activation and commercial terms.
1. Add Trackly to your existing backend
The Trackly API base URL is:Authorization: Bearer <Trackly API key> and Content-Type: application/json
for server-side requests. Keep that key in your existing backend’s secret store.
The browser receives only temporary headset credentials.
Create one reusable browser agent per salesperson with
Create an Agent:
externalSubject from your authenticated server-side identity. Store and
reuse the returned agent mapping under the same issuing API key; omit number.
After an uncertain creation response or 409 agent_exists, use
List Agents to find the intended mapping.
Expose these operations through your existing authenticated backend. The SDK
calls your functions; those functions call Trackly:
Session and call creation require an
Idempotency-Key. Persist the attempt key
and original input before submission, enforce user ownership on every operation,
and return the parsed response envelope unchanged. A timeout must not trigger a
new call attempt. The callback reference
contains exact signatures, responses, and an adapter example for these six methods.
2. Replace the browser audio integration
Load the downloaded script once in the same component that owns your current softphone. It exposeswindow.TracklyVoice.createVoiceBrowser.
This example uses your existing backend adapter, audio element, selected devices,
and status renderer. They are application dependencies, not new Trackly services:
enableHeadset() once on a fresh helper when the user enables your softphone.
It checks for earlier work and then connects the headset. If recovery is required,
show an explicit cleanup action using voice.disconnect() and wait for confirmed
cleanup before connecting. Keep this helper for later calls in the same component.
Use HTTPS, allow microphone access, and retain your existing playback control for
browser autoplay restrictions. Device selections are fixed for one helper
instance. If your existing Salesforce wrapper needs new script or media origins,
see the optional Salesforce configuration reference.
You can keep your current backend and Salesforce component type.
3. Connect your existing buttons
Your Call button supplies the selected owned caller number and contact number, both in E.164 format:error.code. Do not automatically retry call creation.
Disable new calls while
busy is true. startCall() resolving means the call was
admitted; display the conversation as connected when call.state is
connected. Local media: "active" alone is not proof that the telephone was
answered. The SDK already polls call status; do not add a second polling loop.
Test in your existing Salesforce dialer
Start with one salesperson and a consenting test recipient:- Connect the headset, click your existing Call button, and verify the selected telephone receives the call.
- Check speech in both directions, mute, keypad, and hangup from each end.
- Place a second call after cleanup. Check that duplicate clicks do not place another call.
- Reload the component and test logout/recovery. Preserve any unknown attempt until your backend and Trackly resolve it; do not redial around it.