Skip to main content

Server-side integration

ELSA token integration options​

Integrating the ELSA API through calls from the customer's backend server offers the simplest and quickest way to begin (and likely the most secure option). However, it is less scalable than directly calling the ELSA API from the client's applications. In this approach, the customer's backend servers typically receive audio and metadata from the end-user client apps (web or mobile) to be submitted to the ELSA API. The servers then send requests to the API, receive the results, and return them to the client app (either as received from ELSA or after some post-processing). Below is a simplified diagram illustrating this process:

Docusaurus Plushie

In this implementation the customer backend server keeps the ELSA token securely, which can not be abused by malicious end clients, as the client app does not have access to it. It is up to the customer to ensure (via authentication or other means) that the client apps are entitled to perform the voice queries to the customer’s backend. In this implementation the most simple ELSA token is sufficient: default token without any expiration set as provided by ELSA when signing up for an API account. Note that in the example diagram above we could either integrate it using single-file mode or streaming, although single-file implementations are way simpler.

Client-Side integration​

In a client-side integration, an ELSA-token must be present in the client app for direct authentication with the ELSA API servers. This typically occurs in web and mobile implementations, where the client communicates directly with the ELSA servers. It is important in this implementation to consider the secure storage of the ELSA token within the client application, to prevent potential misuse by end-clients for their own projects or other forms of abuse. Misuse of the ELSA token beyond the intended customer use can lead to increased API usage and subsequently higher API costs for the customer.

In the following section, we explore the options provided by ELSA to support our customers and mitigate the risk of misuse. Ultimately, it is the responsibility of the client to safeguard against abuse of their ELSA token by end users.

We offer two integration options with different levels of security:

  • Stand-alone tokens - Lower level of security, not recommended
  • Server-supported tokens - Higher level of security

For further information on securing an API and the considerations associated with each implementation, we recommend reading this article.