Skip to main content

Server-side integration

ELSA token integration options​

Integration of the ELSA API via customer’s backend server calls is the easiest and fastest way to get started (and probably the most secure). On the other hand, it is less scalable than calling the ELSA API directly from the client’s applications. In this solution, the customer backend servers will usually receive from the end-user client apps (web or mobile) the audio and metadata to be submitted to the ELSA API. The servers then make the request to the API, receive the results, and send them back to the client app (either exactly as they come from ELSA or after some post-processing. A simple diagram is shown below:

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 in order for it to directly authenticate with the ELSA API servers. This usually happens in web and mobile implementations where the client calls directly to the ELSA servers. In this implementation it is important to consider how securely stored is the ELSA token in the client application, in order to prevent that the end-client uses the ELSA token for their own projects or abuses it in some other ways. Abuses of the ELSA token outside of the intended use by the customer will usually result in an increase of API usage and therefore an increase of the API cost for the customer.

In this section we discuss what options ELSA is making available to support our customers and reduce the likelihood of this to happen. It is ultimately the responsibility of the client to ensure that there is no abuse of their ELSA token by end users.

We support 2 different integration options with different levels of security:

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

To read more about securing an API and the caveats of each implementation we recommend reading this article.