Using the HTTP API connector in advanced use cases
Last updated
Was this helpful?
Last updated
Was this helpful?
Hi dear App Builder,
This documentation showcases advanced use cases using the HTTP API Connector. It will expose three use cases to handle API at Scale:
Handle Bearer token in Header - Static authentication
Execute a first API Call for Authentication
Handle Token in Token - Dynamic Authentication
This use case is useful when you have an API that needs a Bearer Token (Token Access) in the header of your API call. In this situation, we suppose that the access to your data is static. It is assumed that only one “service account” is accessing a non-variable data item.
In order to set up this you have to create an HTTP API Connector and add Template > Header option as below at the connector level.
Then you have to use your API to create a Query from this Connector and call your application Endpoint. The Header with the Bearer Token will be systematically sent to your SaaS API.
The first use case is a classical one in the software industry. However, APIs often need to use a temporary access token, dynamically retrieved when a first authentication call is made. This access token is then sent during the application call, along with parameters, to retrieve data.
This solution is effective, and here again, the account service is static. Depending on the API, some parameters are requested, as in the example below with 4 parameters:
a grant_type
an account
a username
a password
In this case, the call is encrypted (HTTPS) and sent as a POST. We can do even better in terms of security, as we’ll see in the 3rd scenario.
Again, you have to use your API to create a Query from this Connector and call your application Endpoint.
Finally, the state of the art offers us a third situation, which works very well in an embedded analytics context. In this situation, a software editor (in SaaS for example), wishes to integrate visualizations and show data from Paul to Paul, and data from Mary to Mary, who are two users with different rights.
In this context, the ideal scheme is for the SaaS vendor to manage authentication, with an initial call to its Authentication API. The access token generated by this call can then be sent dynamically to Toucan, in a JWT.
When Toucan is used in an embedded analytics context, it can open this JWT to extract user attributes. These user attributes may contain token access sent by the SaaS embedding Toucan visualizations.
Authentication — Toucan Doco documentation
Finally, this user attribute containing the access token is sent in the header of an API call, as seen in the first scenario.
The screenshot below shows the API connector that dynamically injects user attributes into a header. These attributes come from the JWT.
As always, you have to use your API to create a Query from this Connector and call your application Endpoint. Why not with some parameters if needed, here from our beloved Date Selector.
Thanks for using Toucan and see you soon to share your experience with our Product!
