> ## Documentation Index
> Fetch the complete documentation index at: https://www.text.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Implicit grant

> Use the OAuth implicit grant to get an access token directly in the redirect URL.

The OAuth spec has moved toward the [authorization code grant with PKCE](/docs/authentication/oauth-authorization/authorization-code-grant#pkce-extension) for browser-based apps, so use that flow for new apps. Text still supports the implicit grant for Web app clients that already depend on it.

With the implicit grant, the user is redirected to the Text OAuth server and, after authorizing your app, redirected back with `access_token` included directly in the URL fragment. This flow never issues a refresh token — when the token expires, the user has to authorize your app again.

## Implementing the implicit grant

### Step 1: Create an OAuth client

Go to [Settings → API access → OAuth clients](https://www.text.com/app/settings/integrations/api-access/oauth-clients) and create a new OAuth client. Configure:

* **Display name** — a name to identify your OAuth client.
* **Redirect URI whitelist** — where users are redirected after authorization. See [Redirect URIs](/docs/authentication/oauth-authorization#redirect-uris) for the rules governing this value.
* **Access scopes** — the scopes your app needs. See [OAuth scopes](/docs/authentication/scopes) for the full list.
* **Client type** — **Web app**.

After creation, Text shows your **Client ID** once — you don't need a Client Secret for this flow.

### Step 2: Redirect to the authorization endpoint

```url theme={null}
https://accounts.livechat.com/
```

| Parameter | Required | Description |
| - | - | - |
| `response_type` | yes | Value: `token`. |
| `client_id` | yes | Your OAuth client's **Client ID**. |
| `redirect_uri` | yes | One of the URIs configured for your OAuth client. See [Redirect URIs](/docs/authentication/oauth-authorization#redirect-uris). |
| `state` | no | An anti-forgery token to mitigate <a href="https://en.wikipedia.org/wiki/Cross-site_request_forgery" target="_blank" rel="noopener noreferrer">cross-site request forgery</a>. |

```shell title="Example redirection to the Text OAuth server" theme={null}
https://accounts.livechat.com/
  ?response_type=token
  &client_id=9cbf3a968289727cb3cdfe83ab1d9836
  &redirect_uri=https%3A%2F%2Fmy-application.com
  &state=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
```

### Step 3: Get the access token from the URL

After the user clicks **Allow**, Text redirects them back to your `redirect_uri` with `access_token` in the URL fragment:

```shell title="Example redirection back to the app" theme={null}
https://my-application.com/
  #access_token=test_DQTRHGbZCFkAoss4Q
  &token_type=Bearer
  &expires_in=28800
  &state=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
```

| Parameter | Description |
| - | - |
| `access_token` | The token you use to call Text APIs on behalf of the user. |
| `expires_in` | The number of seconds until `access_token` expires; 28800 by default. Once it expires, repeat this flow to get a new one. |
| `token_type` | Value: `Bearer`. |
| `state` | The `state` value you sent in the authorization request. |

Compare the returned `state` with the value you sent in Step 2, and reject the response if they don't match.

### Step 4: Use the token in API calls

Extract `access_token` from the URL fragment and keep it in memory. Storing it in `localStorage` or a cookie leaves it readable by any script that runs on your page, including through XSS. Caching an in-memory token still avoids redirecting the user to the Text OAuth server on every visit within the same page session.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.