> ## Documentation Index
> Fetch the complete documentation index at: https://developers.pleo.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Tokens Overview

In OAuth 2.0, **access tokens** and **refresh tokens** are used to securely access protected Pleo APIs without exposing user credentials.

This page explains *what tokens are*, how they behave, and the rules integrations must follow when using them. It does not describe implementation details, which are covered in the linked lifecycle guides.

Both access tokens and refresh tokens must be treated as **opaque values**. Integrations must not inspect, decode, or rely on token structure, contents, or format.

## Access Tokens

Access tokens allow your integration to call Pleo APIs on behalf of an authorised user, within the limits of the granted scopes.

* Issued by Pleo’s **Authorisation Server**
* Sent with each request to Pleo **resource servers**
* **Short-lived** and expire after a limited period

<Note>
  The access token lifetime is provided in the `expires_in` field of the token response.
</Note>

Your integration should proactively refresh access tokens **before** they expire to avoid failed API calls or degraded user experience.

## Refresh Tokens

Refresh tokens allow your integration to obtain new access tokens **without requiring the user to reauthenticate**.

* Longer-lived than access tokens
* Lifetime is **not fixed** and must not be assumed
* Valid for **at least 60 days**, but may expire or be revoked earlier

<Note>
  If an expired refresh token is used, all active refresh tokens for that authorisation are invalidated to prevent replay attacks.
</Note>

## Token Opacity and Safety

Access tokens and refresh tokens are **opaque strings** issued by Pleo.

<Note>
  Do not parse, decode, or infer meaning from token values. Their format is not guaranteed and may change without notice.
</Note>

Your integration must store tokens securely and present them back to Pleo APIs **exactly as received**.

## Token Replacement Rules

When refreshing tokens:

* A **new access token** and **new refresh token** are issued
* **All previous access and refresh tokens must be discarded immediately**
* Reusing old tokens may result in authentication failures or revoked sessions

Integrations must always persist and use **only the latest token pair**.

## Common Token Scenarios

### Access Token Expired

* Use the refresh token to obtain a new access token
* Do **not** prompt the user unless refresh fails

### Refresh Token Expired or Revoked

* Restart the OAuth 2.0 authorisation flow
* Prompt the user to reauthenticate and grant consent again

## FAQs

<Accordion title="What is the difference between an integration, application, and OAuth 2.0 client?">
  These terms describe different parts of how OAuth 2.0 works in the Pleo platform.

  The difference between an **integration**, **application**, and **OAuth 2.0 client** is explained in the [OAuth 2.0 Concepts and Terminology](/docs/current/authentication/oauth/oauth-overview#concepts-and-terminology) section.
</Accordion>

## Related Reading

* **[Centralised Token Refresh](/docs/current/integration-design/auth/oauth/token-lifecycle/integration-design-auth-oauth-centralised-token-refresh)**\
  Design a single, reliable mechanism for refreshing tokens across your system.

* **[Race Condition Prevention](/docs/current/integration-design/auth/oauth/token-lifecycle/integration-design-auth-oauth-race-condition-prevention)**\
  Prevent duplicate refresh requests when multiple processes detect expiry simultaneously.

* **[Secure Token Storage](/docs/current/integration-design/auth/oauth/token-lifecycle/integration-design-auth-oauth-secure-token-storage)**\
  Store access and refresh tokens safely in backend and frontend environments.

* **[Handling Refresh Token Expiry or Revocation](/docs/current/integration-design/auth/oauth/token-lifecycle/integration-design-auth-oauth-refresh-token-expiry-revocation)**\
  Recover gracefully when refresh tokens are no longer valid.