OAuth consent: account, level and permissions no longer granted
The MCP consent screen asks you to choose an account and a company, does not grant write access with View level or the permissions of modules blocked in Test, and the request expires after 5 minutes.
14 October 2026
We have changed the screen where a person authorizes an application to work with Factuarea over OAuth (the one that opens at /oauth/authorize). No API operation and no MCP tool changes; what changes is what that screen lets you grant.
- You choose account and company. The screen lists your own companies and those of your clients' accounts, each with the account it belongs to and your access level, View or Operate. The access you grant stays bound to that single company, as before.
- With View level, read-only. If you reach the company with View access, the screen only offers read permissions: those ending in
.readand thefactuarea.readmacro. If an application tries to confirm write access anyway, the answer is403 invalid_scopewithread_only_restricted_scopes. Before, the application obtained those permissions and every write call was rejected one by one; now it never holds them. - In Test, without the modules the sandbox does not offer. The permissions of VeriFactu, the WhatsApp assistant, the document Vault, the Stripe, GoCardless, Monei, Slack and Teams integrations, webhooks and task integrations are not granted in the Test environment (
test); the confirmation answers403withsandbox_restricted_scopes. The selector now reads Live · Test. - The request expires. You have 5 minutes from the moment the screen opens, and the screen itself tells you how many are left.
Tokens already issued are not touched. If an application of yours asked for write access on a View-level company, it loses nothing it could actually use: those calls were already failing. The only difference is that it now finds out at consent instead of on the first write attempt.
Details are in connect a client and in what the screen grants by level and environment.