Ender Turing provides a REST API so that other systems can read and write much of the same data you work with in the web interface — conversations and their metadata, summaries, quality scores, and report data.

Typical reasons to use it:

Setting up API access means creating (or choosing) a user account with a suitable role, and then using that account from your integration.

Access is governed by the role assigned to the account, on two levels.

Reaching the API reference. The API Documentation item in the Help menu, and the reference it opens, are available to roles your administrator has configured for it. The reference is a convenience for the people building an integration, not something the integration account needs. If you cannot open it, check Roles & Permissions or ask your administrator how roles are configured, rather than widening the integration account's role.

Calling individual endpoints. Every endpoint enforces its own permission, and read endpoints also apply the same scope rules as the web interface — a role scoped to a team or to the user's own conversations returns only that subset through the API too. An integration account sees exactly what that account's role allows, no more.

The interactive reference opens in a new browser tab. It documents how an integration signs in, every published endpoint with its parameters, request body, and response schema, and the filtering and paging options, and it lets you try requests directly while signed in.

Use the reference as your working endpoint list — it always matches the version you are running, which is why this article does not repeat endpoint details. If an integration needs something you cannot find there, contact support rather than guessing at a request shape.

Creating users requires the Manage Users permission.

Store the account's credentials in your own secrets manager. If they are lost, an administrator must issue new ones, which will break any integration still using the old ones.

Session API is a predefined role intended for integration accounts. It covers working with conversation data and quality scores and does not include configuration-management permissions, so an integration account using this role cannot change your system settings. Review exactly what it grants on the Manage Roles & Permissions tab before assigning it.

Predefined roles such as Session API ship read-only: you can open one on the Manage Roles & Permissions tab to review what it grants, but you cannot change it. To give an integration a different set of permissions, create a role of your own — the Create Role dialog offers Create from existing, which starts from a copy of the role you pick — and assign that role to the account instead. See Roles & Permissions for how to configure roles, and Users & Agents for the rest of account management.

Your integration signs in with its account before making any other call. The sign-in request, the response fields, and the host to use for all following requests are documented in the interactive API reference (Help → API Documentation), which always matches the version you are running. The token lifetime is not configurable in the interface; contact support if your integration needs a different value. Sign in once and reuse the token until it expires; do not sign in before every request.

If an integration cannot sign in, an administrator should review the account on the Manage Users tab.

On Ender Turing cloud, all traffic passes through a web application firewall, and automated clients are sometimes flagged as bots. When that happens the integration receives a challenge page — an HTML response instead of the JSON it expected, with a Ray ID shown on the page — which it cannot pass on its own, and retrying keeps returning the same page.

Contact Ender Turing support with the Ray ID, or failing that the time of the request, the address your integration calls from, and what it was calling, so that support can add an exception for your integration.

The reference lists the full published set; these are the capabilities most integrations rely on.

Reading conversation data — list conversations with filtering, sorting, and paging; fetch one conversation in full; fetch its generated summary; fetch all quality scores recorded against it.

Transcript text is not part of the published endpoint set, so an integration that needs the spoken content itself cannot be built from the API alone. Conversation records carry the metadata and analysis derived from the transcript rather than the transcript, and the summary endpoint returns the generated summary. If your integration genuinely needs raw transcripts, contact support and describe the use case — the right approach depends on your deployment.

Writing data in — upload an audio file for transcription and analysis; create a conversation from chat data; create a conversation with no audio or transcript, for quality scoring of non-conversation work; record a quality score.

Ingestion is accepted, not completed, when the call returns. A successful upload or chat import gives you the new conversation's identifier straight away, but transcription, analysis, and indexing continue in the background, and how long they take depends on the recording's length and how busy the system is. Reading the conversation back immediately will return incomplete data, or a "not found" error while indexing is still in progress. Treat both as "not ready yet" rather than as a failed upload: poll the conversation at a sensible interval and wait until it is marked as processed before pulling summaries, scores, or analysis.

Reporting — read the aggregated figures behind the dashboard and reporting screens.

Responses reference agents, teams, topics, and scorecards by identifier. Conversation responses already carry the agent's own details alongside the agent identifier, so agents usually need no second call.

For the rest, the list endpoints that turn identifiers into names are configuration reads, and the Session API role does not include them — an integration using that role unchanged will be refused. Because that role cannot be edited, an integration that needs those names has to run on a custom role: copy Session API with Create from existing, add the view permissions for teams, scorecards, or analytics to the copy, and assign the copy to the account. Then fetch each list once and cache it rather than resolving identifiers one at a time.

Listing conversations accepts the same filter expressions as the Conversations screen, so a report you can produce in the interface can also be produced through the API. Several filters can be combined in one expression.

The expression format is not written out in the interactive reference, so build filters in the interface rather than composing them by hand:

The parameter name and format are identical in both places. See Conversations for what each filter does.

One caveat when copying: browsers often hand you the address-bar value percent-escaped, with % followed by two hex digits standing in for characters the URL cannot carry directly. Your HTTP client will escape the parameter again on its way out, and the double-escaped value will not be read back correctly — a filter expression that combines several conditions typically arrives as one malformed condition. URL-decode the copied value once before passing it to your client, and let the client do the escaping.

Results are paged; the paging parameters and their limits are in the reference. For bulk exports, do not page deep into one large result set — split the export by time instead: run one query per day or per week, page through each window until it is exhausted, and move on. Narrowing with filters works the same way. As a bonus, a date-partitioned export is easy to resume after a failure and easy to re-run for a single window when historical data changes.

To cut off an integration, deactivate its account under Settings → Users & Agents → Manage Users (untick Is Active) — see Users & Agents.