Apps let you connect external platforms — such as telephony providers and communication tools — to Ender Turing. Once connected, Ender Turing can access call recordings, agent information, and other data from those platforms to power speech analytics and agent coaching.

The Apps section has two main areas:

Only users with the Marketplace Configuration permission can access the Apps section. This permission controls the ability to browse, install, configure, and uninstall apps, as well as view monitoring details such as WebRTC observability.

On the app details page you can see:

If the connection has failed, click the help icon on the status chip to see the error message, a list of any failed accounts, and a Change app credentials shortcut.

Available actions (accessed through the actions menu):

Apps that sign in with an API key or token — such as Fireflies.ai — let you replace those credentials at any time, whether or not the connection is currently healthy. This is what you use for a planned key rotation, after regenerating a key in the external service, or when a key has expired.

Change app credentials appears for apps that authenticate with a key or token and hold a single set of credentials. Apps that hold several accounts use Manage accounts instead, and apps that sign in through OAuth are re-authenticated by repeating their sign-in flow rather than by editing a form.

For apps whose pre-recognition call duration is a reliable talk-duration, Ender Turing can skip speech recognition for calls shorter than 5 seconds. The call still appears on the All Conversations page as a processed record with the duration, the agent attribution, and any provider-supplied metadata. Because no transcript is produced, the record has no transcript-driven content such as speaker turns, words count, or AI summaries.

The skip applies only when all of these are true:

For other conversation apps (such as Aircall, GoHighLevel, Zendesk Voice, or Zendesk Chat), short calls are not skipped — they go through normal download and recognition even if they turn out to be very brief.

For WebRTC, the browser extension reports the duration with each recording and applies the same idea independently: recordings shorter than 5 seconds, and unusually small recordings (for example, an empty audio file uploaded by the extension), are kept as records with recognition skipped.

The Genesys app uses a dedicated install dialog and supports scoping which conversations Ender Turing ingests by division and queue. You can pick this scope at install time and change it later.

The data-scoping editor appears both in the Genesys install dialog and in the post-install Manage Genesys data fetching action. The behavior is the same in both places.

Each row is one filter. A filter selects:

How filters combine:

Working with the editor:

Validation that blocks Save:

What "ingest by division" and "ingest by queue" actually mean:

If you see a conversation that looks unexpected for the division you configured, open the Session details dialog from the conversation page and check the Info section. For Genesys-ingested conversations you will find:

These fields are populated as conversations are newly ingested; existing conversations from before this change do not carry them.

Clearing every row and saving (no filters) returns the integration to ingesting every conversation in your Genesys organization.

Genesys outbound (dialer) conversations carry a link to a contact-list record that can hold custom columns your organization defined — for example a case type, a sub-type, or an internal identifier. When enabled, Ender Turing fetches an explicit, approved set of these columns for outbound conversations, stores them alongside each conversation, and publishes their values as CRM Status entries so you can see and filter by them.

This is an opt-in, best-effort feature. It is off by default, it never runs while disabled, and it only affects outbound campaign conversations — inbound and non-campaign conversations are untouched.

Who can configure it: the same users who can reach the Genesys app — those with the Marketplace Configuration permission. There is no separate per-user setting; the configuration applies to the whole Genesys installation.

You configure enrichment in two places, with identical behavior: the Genesys install dialog, and the post-install Manage Genesys data fetching action.

Only the fields you list are ever stored. To read them, Ender Turing retrieves the contact record from Genesys, which contains far more customer data (names, phone numbers, policy details, and so on); it immediately keeps only your approved columns and discards the rest, which is never stored or logged. Select only fields you are approved to store in Ender Turing.

A warning next to the field list reminds you that published values become visible as CRM statuses and filter choices across Ender Turing, and that you should avoid high-cardinality fields such as unique customer or policy identifiers. The CRM status choice list is organization-wide and unbounded, so selecting a column with one distinct value per customer would add one entry per value and make the filter hard to use.

Every selected contact field gets its own CRM status prefix for {field} text box, listed under the field selector. The prefix is the readable label that appears in front of the raw value wherever the CRM status is shown.

Installations configured before prefixes existed keep working. Their fields start with empty prefixes, so they publish raw values until you set labels.

Published values behave exactly like any other CRM status in Ender Turing. Once conversations carrying them are ingested, you can:

The raw values also stay available on each conversation: open the Session details dialog from the conversation page and check the Info section for genesys_outbound_contact_data. Nothing is lost if you change a label later.

Field enrichment uses two Genesys permissions, and they are needed at different moments:

Loading field names is an explicit action you take while configuring the form, so a customer that does not use this feature never needs either permission. If Fetch fields fails, a warning appears reminding you to check Outbound > Contact List > View or to enter names manually — you can still type field names by hand and save.

Use Update settings from the actions menu to change the following:

Genesys can record the same call from two perspectives:

Ender Turing ingests recordings from either perspective and assigns the agent to the correct channel automatically, so transcripts and analytics attribute speech to the right speaker regardless of which side Genesys recorded.

How Ender Turing picks which recordings to ingest depends on whether the call was transferred between agents:

When one agent handles the whole call — and that call has been recorded both trunk-side and station-side — Ender Turing keeps the trunk-side copy and skips the station-side duplicate. Trunk-side captures the same conversation plus IVR, queue, and hold audio that station-side omits. If the trunk-side recording is not playable (for example, archived, restoring, or in an error state), the station-side copy is kept instead so the call is not lost.

Calls that have only a station-side recording — such as internal or agent-to-agent transfers that never go through an external trunk — are still ingested. The single agent is attributed as expected.

When a call passes through more than one agent (a transfer chain) and every serving agent leg has its own station-side recording, Ender Turing keeps one station-side recording per leg — each attributed to the agent who actually served that leg — and drops the whole-call trunk copy. Each agent leg becomes its own conversation in Ender Turing, so a three-agent transfer shows up as three conversations, one per agent, with the correct name on each.

Dropping the whole-call trunk in this shape avoids a duplicate record of the same conversation and prevents the whole call from being attributed to only the last agent. The trade-off is that the pre-agent IVR / queue wait and customer-side on-hold audio the trunk alone carries are not part of the audio for these conversations; the routing context still survives on each conversation as metadata (queue, hold segments, flow).

The trunk is kept as a backstop when at least one serving leg is missing its station-side recording — that leg's audio only exists in the trunk, so dropping it would lose an agent's call. In that case, the whole call is ingested as a single conversation from the trunk, attributed to the last agent in the chain, matching the single-agent behavior above.

Legs where the agent only rang (and was never connected) and consult / internal handoff legs that never served the customer do not get their own conversation, even if a station-side recording exists for them. Only agents who actually served the customer are counted as separate legs.

To verify which perspective recorded a conversation, open the Session details dialog from the conversation page and check the Info section:

The Fireflies.ai app ingests Fireflies meeting recordings — from Zoom, Microsoft Teams, and Google Meet — as transcript-first conversations. Each meeting becomes a conversation with one channel per Fireflies speaker ID. If the resolved agent appears under the same non-generic label on several IDs, those agent IDs are merged into one channel. The meeting's mixed recording is attached for playback when your Fireflies plan exposes it.

Before you install, get your Fireflies API key from your Fireflies.ai account. Sign in to Fireflies, open the developer/integrations area (the Fireflies API section, listed under Integrations or Developer settings), and copy the API key. This is the only credential Ender Turing needs.

After installing, set the Timezone you want meeting times shown in — see Fireflies.ai settings. Until you change it, meeting times are shown in UTC.

Use Update settings from the app's actions menu to change:

Fireflies reports meeting times in UTC. Ender Turing converts each newly imported meeting's start time into the timezone you pick here, so the date and time you see on the conversation — in Conversations, in date filters, and in analytics — match your team's local clock instead of UTC.

To change it:

What to expect:

For each completed Fireflies meeting in the sync window, Ender Turing creates one conversation with:

Each conversation is created as a call with Fireflies.ai as its queue name. Because the transcript already exists in Fireflies, Ender Turing does not re-run speech recognition — the imported transcript is what powers all transcript-based analytics.

A Fireflies meeting that is still being processed (the transcript is not finalized yet) is not imported during the sync that first sees it. The integration remembers the meeting and checks it again during each periodic synchronization, creating the conversation only after Fireflies marks the transcript as complete. If the meeting is later deleted in Fireflies, Ender Turing stops retrying it.

Ender Turing's periodic synchronization looks for meetings by their start time, and Fireflies does not always publish a meeting the moment it starts — a long meeting, or one whose processing is queued, can only become visible some time after the fact.

To avoid missing those, each periodic synchronization does not resume exactly where the previous one stopped: it rewinds and re-scans roughly the last 8 hours of already-covered time. A meeting that Fireflies published only after Ender Turing had already scanned its start time is therefore picked up by a later run. Meetings that were already imported are recognized and not duplicated.

What this means in practice:

If you regenerate your API key in Fireflies, or rotate it on a schedule, update it in Ender Turing through the Change app credentials action — you do not need to uninstall and reinstall the app, and you do not need to wait for the connection to start failing. See Updating app credentials for the steps.

Note that the stored key is never displayed back to you: the Fireflies API key field shows ****** and stays optional, so you can open the dialog, click Check to confirm the current key still authenticates, and close it without changing anything.

During synchronization, Ender Turing obtains the meeting's audio recording URL when the Fireflies plan exposes it. After the conversation is created, a background task downloads the recording, converts it into Ender Turing's standard playback format, and attaches it to the conversation. The audio player on the conversation page then plays this mixed recording.

If your Fireflies plan does not expose the audio URL — Fireflies requires a paid plan for this — the conversation stays transcript-only. The transcript, scoring, summaries, and other transcript-based features still work the same way; only the audio player is unavailable.

Fireflies lists who was invited to a meeting by email, and labels transcript speakers by name — but it never says which email belongs to which speaker. Ender Turing therefore decides two things separately for every imported meeting:

Because the two are decided independently, a meeting can end up attributed to an agent whose channel could not be identified.

Ender Turing recognises your people by email. An email counts as one of your agents when it matches that agent's phone number, or one of the alternative numbers on their record under Agents and Teams. An email that only appears on a linked Ender Turing user account does not count. Several emails on the same agent record stay one person.

The meeting is attributed in this order:

If the chosen email has no agent record yet, Ender Turing reads your Fireflies workspace users once per synchronization and creates an agent for each returned email, storing the email as the agent's phone number. Agents you already have are reused rather than duplicated — including deactivated ones, which are never reactivated or renamed by this. If your Fireflies plan does not expose workspace users, the meeting is imported with no agent.

If two agent records carry the same email — typically because one holds it as an alternative number, or because a deactivated record still has it — Ender Turing cannot tell which person is meant and imports the meeting without an agent. Leave that email on one record only, or merge the duplicates under Agents and Teams (see Merge duplicate agents), and later meetings resolve normally.

Merging keeps the result active only when both records were active, so if one of the duplicates was deactivated, the merged agent is deactivated too. Reactivate it after the merge — otherwise meetings do resolve to it, but are then discarded for the reason below.

This is worth checking first when a Fireflies meeting never appears in Conversations. If the agent chosen above is deactivated at the moment the meeting is imported, no conversation is created for it at all — the meeting is not imported with a different agent, and not imported without one.

The meeting is also recorded as handled, so it is not retried later: reactivating the agent afterwards and running Sync more historical conversations does not bring it back. When someone leaves, keep their agent active until their meetings have been imported.

Once the agent is known, Ender Turing looks for them among the transcript speakers, in this order:

So whenever Fireflies supplies at least one speaker, the meeting gets an agent channel. Only a meeting with no speakers at all keeps the agent with the channel left unset.

If the same person appears under several speaker IDs carrying the same label — which Fireflies does produce — those IDs are merged into a single agent channel. Generic labels such as "Speaker 1" or "Guest" are never merged this way, and only the selected agent's IDs are merged; other speakers keep one channel each.

To see how a meeting was attributed, open the Session details dialog from the conversation and check the Info section. The fireflies entry contains an agent_resolution block recording which rule picked the agent (identity_match_type) and which rule picked the channel (channel_match_type). A channel_match_type of best_effort means step 4 above was used — the channel is a guess and is worth checking before you rely on that meeting for scoring.

To correct it, open Session details and click Edit. This requires permission to edit conversation details. The two decisions are corrected by two separate fields:

A later synchronization will not overwrite your change, because meetings already in Ender Turing are not re-imported.

The Binotel app connects your Binotel cloud PBX to Ender Turing. Calls handled on your Binotel lines, together with their recordings, are pulled in on the regular synchronization schedule and appear in Conversations alongside conversations from every other source, ready for transcription, scoring and analytics.

This is a server-side integration that talks to Binotel directly. It is separate from the Binotel entry in the WebRTC app's Supported services list, which records the Binotel web workspace from the agent's browser instead. You do not need the browser extension to use this app.

Before you install, ask your Binotel administrator for the API credentials of your company account — an API key and an API secret. Both belong to the company as a whole, and the app has no per-line filter: it takes in the calls of every line on the account those credentials open. If part of your Binotel account should stay out of Ender Turing, use credentials for an account whose scope already matches what you want ingested.

Binotel has no configurable settings, so the Update settings action does not appear on its details page.

Installing does not bring in your existing Binotel history. Synchronization starts from the moment you install, and every run — the first one included — covers roughly the last 3 hours, so calls made before that never arrive on their own. To pull those in, use Sync more historical conversations from the app's Actions menu, described under Recordings that are still uploading.

For each Binotel call in the sync window, Ender Turing creates one conversation carrying:

Lines that report a label instead of a numeric extension — typically queue and IVR lines — leave the internal number blank on the conversation; the label itself is not stored.

Binotel's own customer names and employee email addresses are not stored on the conversation either. The employee name reaches Ender Turing only through the agent record, and the email only serves to match a call to an agent you already have — see How agents are recognized.

Only calls that have a finished recording are ingested. Calls with nothing to listen to — unanswered, cancelled, or otherwise never connected — are skipped, so they never appear as empty conversations.

A call that matches an agent also needs that agent to be active, and what counts is whether the agent is active at the moment the call is imported — not whether they were active when the call was made. If the line's internal number or the employee's email matches an agent that is deactivated when the sync runs, the recording is fetched, discarded, and no conversation is created. Deactivating an agent therefore also keeps their older calls out of Sync more historical conversations. A call dropped this way still counts as handled, so reactivating the agent and re-running the resync does not bring it back. If calls from one person are missing, check that their agent record is active before you resync — and when someone leaves, keep their agent active until the calls you need have been imported.

This applies only to calls that match an existing agent. A call that matches nobody — a queue or IVR line whose label is not an extension, reported with an employee email that belongs to no agent in Ender Turing — is imported normally, as a conversation with no agent attached.

Binotel recordings carry both parties on separate channels, with your side on the left channel. Ender Turing uses this, so transcripts attribute speech to the operator and the customer correctly without relying on voice separation.

Each Binotel line is ingested as its own agent, identified by the line's internal number. You do not have to maintain a list of numbers: a line that Ender Turing has not seen before gets an agent record created for it automatically the first time one of its calls arrives, named after the employee Binotel reports for that line.

Because the line is the unit, one person who works from several lines — for example a softphone and a mobile SIM — shows up as several agents. To report on them as one person, select both records under Agents and Teams and use the Merge action; see Merge duplicate agents. Merging is deliberately left to you, because it cannot be undone once done.

The employee name Binotel reports is also used to fill in a blank agent name. If a call matches an agent record that has no name yet — whether matched by number or by email — that record is given the Binotel employee name. Agents that already have a name keep it, so a name you set in Ender Turing is never overwritten by Binotel.

Lines whose internal number is not a plain number — queue and IVR lines report a label rather than an extension — do not get an agent created for them. Their calls are still ingested, and are attributed to an existing agent when the email Binotel reports matches one.

Binotel publishes a call as soon as it ends, but its recording can take longer to finish uploading. A call whose recording is not ready yet is left alone rather than imported without audio.

To catch these, each synchronization rewinds and re-reads roughly the last 3 hours of already-covered time instead of resuming exactly where the previous run stopped. A recording that finished uploading after Ender Turing first saw its call is therefore picked up by a later run. Calls already imported are recognized and not duplicated.

What this means in practice:

Sync more historical conversations re-scans whole days counting back from today: choosing N days covers today and the N − 1 days before it. The slider stops at 90, so the oldest day this action can reach is 89 days before today. Note that the start date shown in the dialog is one day earlier than the oldest day actually re-scanned, so pick a value with a day to spare when your gap is near the limit. A gap older than that cannot be filled from this action — if you need those calls, contact Ender Turing support.

If your Binotel API key or secret is reissued, update it in Ender Turing through the Change app credentials action — you do not need to uninstall and reinstall the app. See Updating app credentials for the steps.

The stored secret is never displayed back to you: the Binotel API secret field shows ****** and stays optional, so you can change the key alone, or open the dialog, click Check to confirm the current pair still works, and close it without changing anything.

The WebRTC app records calls and meetings straight from the agent's browser, using the Ender Turing call recorder browser extension. After installing the app, you can configure the following settings through the Update settings action on the app details page:

Services to record is the list of telephony and meeting platforms your agents' extensions may record on. The extension attaches its recorder only on the platforms selected here — on any other site it stays idle, even if the extension is installed and connected.

To change the list:

The setting applies to the whole organization — there is no per-agent list — and takes effect without reinstalling the app or the extension. Keep at least one service selected: with an empty list the extension has no platform to attach to, so nothing is recorded for anyone.

Zendesk is covered by Zendesk Talk — there is no separate Zendesk entry.

For the WebRTC app, a dedicated monitoring view helps you track the health of agents using WebRTC for calls.

At the top, a summary displays:

Below the summary, a table lists each agent with the following columns:

The Paused column is informational only — it does not affect the health summary chip or the not-OK agent count.

Click the Last ping or Paused cell for any agent to open a telemetry history dialog. The dialog shows historical data for that agent in the selected mode:

The dialog contains:

If no telemetry data exists for the selected date range, the behavior depends on the mode. In connectivity mode, the entire range is treated as offline and shown in the chart and table. In pause mode, the dialog shows an empty state message. If the data fails to load, you can retry from within the dialog.

The Current issues column shows issue codes that describe what is going wrong for an agent. Common issues include recording failures, invalid tokens, script injection failures, and permission failures.

When an issue includes a related service name, it is displayed alongside the code (for example, "recording_failed (ServiceName)").

When a recording failure issue includes additional diagnostic metadata, a button appears next to the issue. Click it to open a dialog titled Recording failure metadata, which displays technical details about why the recording failed. This information can help you diagnose and resolve the problem.

Muting does not fix the underlying issue — it only hides the agent from the active list so you can focus on other agents that need attention.