Authentication
How to authenticate your users and call the LiveSwitch API from your own application.
LiveSwitch uses OAuth 2.0 for authentication. Every API request requires an access token with the Bearer scheme in the Authorization header. This page explains how to get an access token.
Using these docsThis documentation site automatically creates an access token from your LiveSwitch account after you log in. You can use this access token to try API calls directly from these pages. This access token is only for tests in the documentation. It is not for use in your application. The steps below explain authentication for users of your application.
Base URL
Send all API requests to this URL. Each endpoint path starts with /v1.
https://public-api.production.liveswitch.com
The login and token endpoints use a different host, https://id.liveswitch.com.
What you need
| A Developer App | Contains your client_id, client_secret, and registered callback URLs. To request a Developer App, email [email protected] with the subject "Create a developer app". Include your callback URLs, application name and purpose, and primary developer contact. |
| A LiveSwitch User Account | Your application authenticates as this account. If you need an account, contact [email protected] or start a free trial. If you work for an existing customer, ask that customer to provide an account. |
| An access token | You receive this at the end of the flow below. Include it in Authorization: Bearer {access_token} on every request. |
How the login flow works
The login flow has these steps:
- Your application sends the user to a LiveSwitch login URL that uses your
client_idand callback URL. - The user sees your Developer App's name at login. The user logs in. The user authorizes your application.
- For Code Exchange, LiveSwitch redirects to your callback URL with a
code. For Token Exchange, it returns anaccess_token.
Two flows are available:
| Code Exchange | Token Exchange | |
|---|---|---|
| Best for | Apps with a backend | Browser-only apps (SPAs) with no backend |
Needs client_secret | Yes | No |
| Refresh without re-login | Yes, via refresh_token | No. Requires another redirect through login |
| Security | More secure | Less secure |
1. Send the user to the login URL
GET https://id.liveswitch.com/authorize
?response_type=code
&client_id={your_client_id}
&redirect_uri={your_whitelisted_callback}
&scope=accounts applications applications.write attributes attributes.write contacts contacts.write conversations conversations.write documents email forms guided-instructions me offline_access openid organizations organizations.write profile projects projects.write recordings spark-templates sparks sparks.write tags tags.write webhooks webhooks.write
&audience=https://public-api.production.liveswitch.com/2. Exchange the returned code for tokens
code for tokensPOST https://id.liveswitch.com/oauth/token
Content-Type: application/json
{
"grant_type": "authorization_code",
"code": "...",
"client_id": "...",
"client_secret": "...",
"redirect_uri": "..."
}Response:
{
"access_token": "eyJhbGciOi...",
"refresh_token": "v1.MjM0NTY3...",
"expires_in": 3600,
"token_type": "Bearer"
}Include access_token in the Authorization: Bearer header on every API call. Save the refresh_token in persistent storage. You need it in the next step. You will receive a new refresh token only after you use the current one.
3. Refresh when the access token expires
Do not wait for a request to fail with 401. Track expires_in. Refresh the access token shortly before it expires. Alternatively, if a request fails with 401, refresh the access token. Then retry the original request once.
Call the same token endpoint with a different grant type:
POST https://id.liveswitch.com/oauth/token
Content-Type: application/json
{
"grant_type": "refresh_token",
"refresh_token": "v1.MjM0NTY3...",
"client_id": "{your_client_id}",
"client_secret": "{your_client_secret}"
}The response uses the same structure. It contains a new access_token and a new refresh_token. Each time, replace your saved refresh_token with the new one. The previous refresh token becomes invalid as soon as you use it.
1. Send the user to the login URL
GET https://id.liveswitch.com/authorize
?response_type=token
&client_id={your_client_id}
&redirect_uri={your_whitelisted_callback}
&scope=accounts applications applications.write attributes attributes.write contacts contacts.write conversations conversations.write documents email forms guided-instructions me offline_access openid organizations organizations.write profile projects projects.write recordings spark-templates sparks sparks.write tags tags.write webhooks webhooks.write
&audience=https://public-api.production.liveswitch.com/2. Read the access token from the redirect
LiveSwitch redirects back with the access token in the URL hash. It does not use a query parameter:
https://your-callback-url.com/path#access_token=abcdefgUse the access token directly: Authorization: Bearer abcdefg
3. Log in again to get a new access token
This flow does not provide a refresh token. To get a new access token, redirect the user through the login URL from step 1. If their LiveSwitch login session remains active, LiveSwitch returns the user directly to your callback URL. LiveSwitch does not prompt the user to log in again.
Callback URLs must be registeredThe
redirect_urimust exactly match a callback URL registered on your Developer App. Otherwise, login fails. This prevents token theft by malicious actors. Requests for callback URL additions or changes go to [email protected]. These requests require your Client ID and the callback URL.
Log out
- Delete the access token and the refresh token that your application saved.
- Send the user to the LiveSwitch logout URL:
GET https://id.liveswitch.com/v2/logout?client_id={your_client_id}
LiveSwitch ends the user's login session.
Scopes
The example login URLs request every scope. In your application, request only the scopes that it needs.
| Scope | Grants |
|---|---|
openid, profile, email | Basic identity information about the user who logs in. Every integration requires these scopes, regardless of its endpoints. |
offline_access | Issues a refresh_token (Code Exchange only) |
organizations | Read the user's organization information |
conversations / conversations.write | Read, create, and update Conversations. The LiveSwitch UI calls Conversations "Sessions". |
projects / projects.write | Read, create, and update Projects |
contacts / contacts.write | Read, create, and update Contacts |
recordings, documents | Read recordings, photos, and documents |
tags / tags.write | Read and manage tags |
webhooks / webhooks.write | Read and manage webhook subscriptions. Only administrators can use these endpoints. Regular users receive 403 on all webhook endpoints, also for read requests. |
sparks / sparks.write, spark-templates | Read and run Sparky AI reports. See the Sparky AI Reports guide |
accounts, applications / applications.write, attributes / attributes.write, forms, guided-instructions, organizations.write | Read or write these resources. Most integrations do not need them. |
Where to go next
These pages provide more information:
For questions, email [email protected]. We will reply promptly.
Updated 6 days ago