Scopes

We use scopes to both describe the access the user is granting and the way in which you would like the user to identify themselves.

Below is a summary of the scopes we provide, please check our discovery document available here to see which particular scopes are supported by a given deployment of our identity service.

  • openid - this scope is required and indicates that you are using our OpenID Connect interface. We will return an id token as described in the OpenID Connect Core spec. You can request specific claims to be present in the id token using the claims parameter described in OpenID Connect Core. For details on what claims we support, please check the claims section
  • offline_access - this scope indicates that you would like ongoing access to the user’s resources, when it is present we will issue a refresh token

Financial institutions

  • id:{bank_id} - if you pass a specific bank id (available via the endpoints listed above) then we will bypass the bank chooser and take the user directly to the selected bank
  • id:all - if you specify this scope we will display a list of all available connections
  • id:api - if you specify this scope we will display a list of the available API based connections
  • id:legacy - if you specify this scope we will display a list of the available legacy (screen scraping) connections
  • id:test - if you specify a type of connection then we will display a list of our test connections. This scope will be enabled by default when creating a new client through our admin portal

The above scopes are mutually exclusive and we will return an error of invalid_scope if more than one of the above is supplied.

Data access

Most data access scopes are available to use in both use cases. The scopes ending in write:all are only available in the second use.

  • transactions:read:all - All transactions
  • transactions:read:in - All incoming transactions
  • transactions:read:out - All outgoing transactions

Note - the above transactions:read scopes are mutually exclusive - if more than one is provided there will be an invalid_scope error.

  • transactions:write - For all transactions that are able to be read it is possible to edit certain fields (e.g. category, notes, etc.). Please see the documentation on the transactions endpoint for details of which fields can be edited. If transactions:write is provided without any transactions:read scope there will be an invalid_scope error
  • transactions:write:all - This allows full access to create transactions, edit all their properties and delete transactions. This scope is only available when issuing tokens for users that are managed by the client (only available for use case 2)
  • accounts:read - Read access to all accounts
  • accounts_details:read - Read access to accounts details such as full account number and sort code. This scope needs to be requested to be enabled for your api client.
  • accounts:write - Write access to all accounts. Please see the accounts endpoint for details of which fields can be edited.
  • accounts:write:all - Full write access including the ability to delete accounts. This scope is only available when issuing tokens for users that are managed by the client (only available for use case 2)
  • beneficiaries:read - Read access to a customers beneficiaries.
  • beneficiaries_detail:read - Read access to beneficiaries details such as address.
  • categories:read - Read access to a customer’s categories.
  • categories:write - Write access to a customer’s custom categories.
  • spending_analysis:read - Read access to a customer’s spending analysis.
  • spending_goals:read - Read access to a customer’s spending goals.
  • spending_goals:write - Write access to a customer’s spending goals.
  • spending_goals:write:all - Full write access to spending goals, including the ability to delete goals.
  • savings_goals:read - Read access to a customer’s saving goals.
  • savings_goals:write - Write access to a customer’s saving goals.
  • savings_goals:write:all - Full write access to saving goals, including the ability to delete goals.
  • standing_orders:read - Read access to a customers standing orders.
  • standing_orders_detail:read - Read access to standing order details such as full account number and sort code.

Payments

  • payee:create - this scope is required to create a new payee.
  • payee:read - this scope is required to retrieve all of the payees that have been created by an API client.
  • payment - this scope is required to initiate a payment.
  • payment:read - this scope is required to retrieve all of the payments that have been initiated with by an API client.
  • standing_orders:create - this scope is required to create new standing orders.
  • recurring_payment:create - this scope is required to create new recurring payments (VRP).
  • recurring_payment:read - this scope is required to read recurring payments (VRP) that have been created.

User management

  • user:create - this scope is only supported with the client credentials grant type. It allows a relying party to create a new user profile.
  • user:read - this scope is only supported with the client credentials grant type. It allows a relying party to access their user profiles.
  • user:delete - this scope is only supported with the client credentials grant type. It allows a relying party to delete a user profile.

Default Scopes

Below are the default scopes that are enabled when first creating a client:

  • accounts:read
  • accounts:write
  • accounts:write:all
  • categories:read
  • categories:write
  • offline_access
  • openid
  • projects:delete
  • projects:read
  • projects:write
  • reauth
  • refresh
  • savings_goals:read
  • savings_goals:write
  • savings_goals:write:all
  • spending_analysis:read
  • spending_goals:read
  • spending_goals:write
  • spending_goals:write:all
  • tax:read
  • transactions:read:all
  • transactions:read:in
  • transactions:read:out
  • transactions:write
  • transactions:write:all
  • user:create
  • user:delete
  • user:read