Skip to main content

How Permissions Work

This guide explains how Fiskl decides what each person and integration can do. Permissions are enforced in three places — the app, API keys, and OAuth apps — and this guide covers how they relate and where they intentionally differ.

The Three Places Permissions Apply​

The same underlying permissions drive access everywhere, but each surface uses them slightly differently.

  • The app. The interface shows or hides menus and buttons based on your permissions. Some actions you lack appear disabled with a tooltip; others are hidden entirely.
  • API keys. A key carries a set of fine-grained permissions, such as invoice.read. You select these when you create the key, and you can only grant permissions you hold yourself. See Create and Manage API Keys.
  • Connected apps (OAuth). An app requests coarser scopes, such as invoicing:read, which expand to a set of permissions. The person authorising the app approves these scopes. See Connect Apps with OAuth.

A Credential Never Exceeds Its Owner​

Whatever a key or app is granted, the real access is always the overlap with what the owner can do:

Effective access = the owner's permissions ∩ the key or app's scopes.

Two consequences follow:

  • A key scoped to invoice.write held by someone who loses invoice access can do nothing — the overlap is empty.
  • Reducing a team member's permissions immediately narrows every key and app they created. There is nothing to re-sync.

The Server Separates Read from Write​

On the server, viewing and changing are distinct permissions for most areas — invoice.read versus invoice.write, payment.read versus payment.write, and so on. This separation is real for the API: a key or connected app granted only read access can view data but cannot change it.

This is why a read-only scope is genuinely read-only, and why you can safely give an integration reports:read without any risk of it altering your books.

Known Differences Between the App and the API​

The app sometimes groups permissions more coarsely than the server does, to keep the interface simple. These differences are deliberate. The table below lists the ones to be aware of.

AreaOn the server and APIIn the app
Accounting (transaction ledger)accounting.read and accounting.write are separate. A key or app with read access gets read-only ledger and report data.The Chart of Accounts and all Reports are visible read-only with accounting.read. But the transaction ledger — Transactions and Multi Journal — requires accounting.write even to view; there is no read-only ledger view. Reconciliation needs accounting.reconcile.
Dashboard financial widgetsRead access (accounting.read) is enough to view ledger and report data.The financial widgets on the main dashboard (key metrics, cashflow, ratios, banking overview, AR/AP aging, category breakdown) require accounting.write. A read-only member sees an empty dashboard but can open the same figures under Reports.
Sensitive permissionsEnforced individually on every request.Flagged inline in the permission grid with a warning (shield) icon, with a confirmation step before granting. Never offered to connected apps.
Scopes vs permissionsAPI keys use the full fine-grained permissions.Connected apps use 18 coarser scopes that each expand to several permissions, so app authorisation is broader than a single permission.
info

This list reflects current behaviour and grows as the product evolves. The Permissions Reference shows, per permission, how it behaves in the app and which scope grants it to an integration.

Sensitive Permissions​

Eleven permissions form the highest-risk set — editing invoice bank details, changing tax rates or FX rates, posting or closing the ledger, inviting users or changing their access, managing credentials, and cancelling the account. Fiskl treats them with extra care:

  • They are flagged inline in the permission grid with a warning (shield) icon and ask for confirmation before you grant them.
  • They are never granted through OAuth scopes, so a connected app can never receive them.
  • A team member can hold them directly, and an API key can include them if the person creating the key holds them.

Common Questions​

If I give someone read-only access, can they still change data through the API?

No. Read and write are separate permissions, and the API enforces them on every request. A read-only key or app can view data but cannot change it.

What can a teammate with accounting read access see in the app?

With accounting.read, they see the Chart of Accounts and all Reports (Profit and Loss, Balance Sheet, Trial Balance, General Ledger, aging, and so on) read-only. What they cannot see is the transaction ledger — the Transactions and Multi Journal screens require accounting.write even to view, because the app does not offer a read-only ledger view. They also won't see the financial widgets on the main dashboard, which require write access. This is a known difference, listed above.

If I remove a permission from someone, what happens to the API keys they created?

Those keys lose that access immediately. A credential's real access is always the overlap of the owner's current permissions and the credential's scopes, recalculated on every request.