> ## 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.

# OAuth 2.0 Client Registration

Integrations using **OAuth 2.0** must register a client with Pleo. Client registration establishes your **OAuth 2.0 client’s identity** and provides the credentials required to securely authenticate users and request access tokens.

Once registered, your **application** can redirect users to Pleo to grant consent and obtain tokens for accessing Pleo APIs.

## Why OAuth 2.0 client registration is required

Client registration enables Pleo to:

* Identify your **OAuth 2.0 client** during authorisation flows
* Display your **application’s** name and branding to users
* Enforce security controls such as redirect URI validation
* Restrict access using requested API [scopes](/docs/current/authentication/api-scopes)
* Issue tokens securely to authorised **OAuth 2.0 clients**

Without client registration, your integration cannot participate in the OAuth 2.0 authorisation flow.

## Information required during registration

Pleo requires three categories of information.

### 1. Human-readable information

This information is displayed to users when they authorise your application.

<Warning>
  Do **not** use Pleo branding in your client information.
</Warning>

* **Client Name**: Your application's name as shown to users.
* **Client URI**: Homepage or landing page of your application.
* **Logo**: Square (1:1), high-resolution logo representing your application.
* **Terms of Service URI**: Legal agreement governing use of your application.
* **Privacy Policy URI**: Explains how user data is handled.
* **Contact Email(s)**: Contact details for responsible developers or support.

### 2. Pleo-specific integration information

These URIs allow Pleo and users to interact with your application.

* **Initiation URI**: Page where users begin connecting your application with Pleo.
* **Settings URI**: Page in your application where users manage or update configuration settings for the integration (for example, accounting periods, mappings, or synchronisation preferences).

### 3. Technical information

This information is required for the OAuth 2.0 protocol.

* **Redirect URI(s)**\
  OAuth 2.0 callback endpoints where Pleo redirects users after authorisation.

  Requirements:

  * Must use HTTPS in production
  * HTTP allowed only for localhost during development
  * Must match exactly (aliases or wildcards are not supported)

* **Requested scopes**\
  Permissions your **OAuth 2.0 client** requests to access Pleo APIs. See [API Scopes](/docs/current/authentication/api-scopes).

* **PKCE support**\
  Required for public clients (SPAs, mobile apps).

  Requirements:

  * Must use `S256`
  * `plain` is not supported

* **Subject type preference (optional)**\
  Defines the default resource context used by your **OAuth 2.0 client**.

## Credentials issued after registration

After successful registration, Pleo provides:

### Client ID

Public identifier of your **OAuth 2.0 client**.

Used to:

* Identify your OAuth 2.0 client during authorisation
* Associate tokens with your client

This value is safe to expose in client-side applications.

### Client Secret

Confidential credential used to authenticate your **OAuth 2.0 client** when requesting tokens.

Security requirements:

* Must be stored securely on a server
* Must never be exposed in browser or mobile code
* Must never be committed to source control

Public clients using PKCE may not require a client secret.

## Redirect URI security requirements

Redirect URIs are strictly validated to prevent token interception.

Requirements:

* Must be registered exactly
* Must be publicly accessible (except localhost for development)
* Must use the `state` parameter to prevent CSRF attacks
* Must not use wildcards

Example:

```html theme={null}
https://example.com/oauth/callback
```

## Testing your OAuth 2.0 client

Before production use:

* Verify redirect URIs are registered correctly
* Complete the full authorisation flow
* Confirm access tokens can be retrieved successfully
* Test token refresh behaviour

Tools such as Postman can be used for testing.

## Outcome

After registration:

* Your application is recognised by Pleo
* Your application can request user authorisation
* Your OAuth 2.0 client can obtain access tokens securely
* Your integration is ready for OAuth 2.0 implementation

## 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

* [Client Configuration](/docs/current/integration-design/auth/oauth/getting-set-up/oauth-client-configuration)
* [OAuth 2.0 Libraries and Standards](/docs/current/integration-design/auth/oauth/implementing-oauth/integration-design-auth-oauth-libraries-and-standards)
* [PKCE and Secured Patterns](/docs/current/integration-design/auth/oauth/implementing-oauth/integration-design-auth-oauth-pkce-and-secured-patterns)
* [OAuth 2.0 Setup Workflow Guide](/docs/current/guides/oauth-workflow-guide)