OAuth 2.0

Overview of OAuth 2.0 within the Upvest Investment API

The Investment API uses opaque access tokens obtained using the OAuth 2.0 Client Credentials flow.

During the onboarding process, each client receives a client ID and a client secret that can be used to request access tokens via our OAuth2 endpoints.

Authentication scopes

The Upvest Investment API supports granular authentication scopes, thus improving security. You can restrict the permissions and data that is requested during authentication by specifying the scopes.

The following table lists available scopes:

Scope	Permissions
`accounts:read`	Read accounts and accounts groups.
`accounts:admin`	Create/update/delete accounts and accounts groups.
`webhooks:admin`	Create/update/delete webhooks.
`webhooks:read`	Read webhooks.
`orders:admin`	Create/update/delete orders.
`orders:read`	Read orders.
`users:admin`	Create/update/delete users.
`users:read`	Read users.
`checks:admin`	Create checks.
`checks:read`	Read checks.
`positions:read`	Read positions.
`reference_accounts:admin`	Create/update/delete reference accounts.
`reference:accounts:read`	Read reference accounts.
`mandates:admin`	Create/update/delete mandates.
`mandates:read`	Read mandates.
`payments:admin`	Payments and withdrawal operations.
`payments:read`	Payments and withdrawal read operations.
`topups:admin`	Top-ups operations.
`topups:read`	Top-ups read operations.
`reports:read`	Read reports.
`taxes:read`	Read tax residencies.
`taxes:admin`	Modify tax residencies.
`instruments:read`	Read instruments.
`fees:admin`	Create and read fee operations.
`fees:read`	Read fee operations.
`portfolios:read`	Read portfolios.
`portfolios:admin`	Modify portfolios.
`reinvestments:read`	Read reinvestments.
`reinvestments:admin`	Modify reinvestments.
`valuations:read`	Read account valuations.

Request a users:read access token to read user data but not be able to change user data. Then request a users:admin access token to be able to onboard new users.

More on available permissions see here. Auth

Once the access token is returned, the token can be used in all requests for the specific required scopes using the standard authorization header as shown below:

Example header

Authorization: Bearer <access_token>

The use of client_credentials alone allows us to identify you and authorise your request. However, it does not protect against a man-in-the-middle attack, where the request can be maliciously modified. To mitigate this risk, there is an additional layer of public key infrastructure in the form of HTTP Message signatures.