# User access tokens Learn about Wise user access tokens. A user access token lets your application make requests to the Wise API on behalf of a specific Wise user. Wise issues a user access token once the user authorises the partner application to perform transactions on their behalf. While the process for obtaining user access tokens is generally the same regardless of partner integration model, it’s worth noting the following differences: - **Enterprise and Correspondent partner integrations** rely on a single profile through which all transactions occur, and so will go through this flow only once. - **Partners using the Embedded Solution model** are transacting on behalf of many Wise account profiles, and so will go through this flow for each user that wants to authorize their application. ## Prerequisites Before you can obtain user access tokens, you must have: - Your **client ID** and **client secret** (retrieve via Developer Hub). - A **redirect URL** (coordinated during partner onboarding with the Wise implementation team). - Created a Wise account and user (how this occurs will depend on your integration model and you’ll be guided by your onboarding team). ## Obtain a user access token Obtaining a user access token requires the following basic steps: 1. Directing the user from your application to the Wise authorisation page. 2. The user logging in and granting permission. 3. Wise redirecting the user back to your application with an authorisation code. 4. Your application exchanging the code for an access token and refresh token. Each step is explained in more detail in the sections below. Please note that while these steps apply broadly to all partner integration models, some details can vary. Guides for specific integration models are coming soon! ### Redirect to authorisation page From your application, direct the user to the Wise authorisation page. This is where the user will grant your application permission to perform transactions via the Wise API. **Wise authorisation page URL path**: `/oauth/authorize?client_id=&redirect_uri=&response_type=code&state=` **Query parameters**: - `client_id`: Your application's client ID. - `redirect_uri`: Your registered redirect URL (must match exactly). - `response_type`: Always `code`. - `state`: A random string to prevent CSRF attacks. Must be verified on callback. The user will see a Wise authorisation page where they can log in to the Wise account (if not already logged in), review the permissions your application is requesting, and approve access. ### Receive authorisation code After the user approves access, Wise redirects them back to your `redirect_uri` with an authorisation code. The URL will appear in the browser in a format like this: `https://your-app.com/callback?code=&state=` You’ll exchange the `authorization_code` value for the token in the next step. Important! Verify that the `state` value matches what you sent in the `state` parameter when redirecting the user to authorise. ### Exchange auth code for tokens Exchange the auth code returned in the previous step for an access token and refresh token by making a request to the [create an OAuth token endpoint](/api-reference/oauth-token/oauthtokencreate). **Endpoint**: `POST /oauth/token` Required data for this request: - `client_id` and `client_secret` - `grant_type` is always `authorization_code` - `code` is the same authorization code value returned from the previous step - `redirect_uri` is the redirect URL coordinated with Wise during onboarding ``` curl -X POST https://api.wise.com/oauth/token \ -u ':' \ -d 'grant_type=authorization_code' \ -d 'client_id=' \ -d 'code=' \ -d 'redirect_uri=' ``` The response includes both the `access_token` and `refresh_token`, along with additional token details like when they expire and the token `scope`. You can now use the `access_token` in all profile-level requests and refresh the tokens prior to their expiration. ## Alternative registration code flow If your application creates new Wise users via API, you can exchange a registration code for tokens instead of using the authorisation code flow. Make a [create an OAuth token request](/api-reference/oauth-token/oauthtokencreate). **Endpoint**: `POST /oauth/token` Required data for this request: - `client_id` and `client_secret` - `grant_type` will always be `registration_code` - `email` will be the user’s email address (in the case of the Correspondent integration model, this is a dummy email provided by Wise) - `registration_code` will be the same registration code value generated for the create user account request ``` curl -X POST https://api.wise.com/oauth/token \ -u ':' \ -d 'grant_type=registration_code' \ -d 'client_id=' \ -d 'email=' \ -d 'registration_code=' ``` The response is the same as the authorisation code flow. ## Using the token Include the access token in the `Authorization` header when making requests on behalf of the user. **Example**: ``` curl -X GET https://api.wise.com/v2/profiles \ -H 'Authorization: Bearer ' ``` ### Managing token expiration User access tokens expire after 12 hours. Refresh the token before its expiration to avoid the following potential expiration errors, like `invalid_grant` and `Unauthorized`. To maintain uninterrupted access: - **Track the expiry time** using the `expires_in` value from the token response. - **Refresh proactively** when 80% of the TTL has elapsed. See the [Refresh tokens guide](/guides/developer/auth-and-security/refresh-tokens) for details about how to obtain new access tokens.