> ## Documentation Index
> Fetch the complete documentation index at: https://docs.panoqore.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Integration modes

> Choose who calls the bank, your code or PanoQore.

A bank connector runs in one of two modes. You choose for each bank, and you can change your mind later.

| | Ledger-only | Full integration |
| - | - | - |
| Who calls the bank | Your own code | PanoQore, with your credentials |
| What you send PanoQore | The credits, entries and bindings you made | Nothing for credits; PanoQore hears from the bank |
| Inbound credits | You report each one with `POST /v1/partners/{partner}/credits` | PanoQore takes the bank's notices and confirms each one |
| Binding a number | Taken on your word | Checked with the bank first |
| Statements | PanoQore reads them, or you upload them | PanoQore pulls and matches them |
| `mode` | `LEDGER_ONLY` | `FULL` |

Both modes keep the same books. A credit posts the same entry either way, debiting settlement and crediting the wallet, and is idempotent on the bank's transaction id.

## Ledger-only

Your code already talks to the bank, and PanoQore keeps the books.

1. The bank tells your code about a credit.
2. Your code reports it. See [Record a credit](https://docs.panoqore.com/guides/named-accounts.md#record-a-credit).
3. PanoQore posts it, or holds it in suspense if it cannot place it.

PanoQore holds no credentials. You can still give it read-only access to the bank's history, so it pulls statements for you, by setting history access to `READ_API`.

## Full integration

PanoQore talks to the bank for you.

1. The bank posts a notice to your workspace's webhook URL.
2. PanoQore asks the bank about that transaction with your credentials.
3. Only what the bank confirms is credited.
4. Each hour, PanoQore also pulls the bank's history and posts anything a notice missed.

In this mode, `POST /v1/partners/{partner}/credits` is refused with `INTEGRATION_MODE_FULL`, so a credit cannot arrive twice by two routes.

## History access

`historyAccess` says how PanoQore gets each day's statement.

| `historyAccess` | Meaning |
| - | - |
| `READ_API` | PanoQore reads the bank's history each morning and matches it. |
| `UPLOAD` | Someone uploads the statement. The day shows as late until they do. |
| `NONE` | PanoQore has no access to the bank's history. Statements are uploaded, as with `UPLOAD`. |

In full integration, PanoQore reads the history whatever `historyAccess` says.

## Switching modes

An admin asks for the switch in the console, under **Connections → Integration mode**, with a reason. Switching changes who can move your money at that bank, so an approver signs it off before it applies.

Full integration, and `READ_API` history access, need credentials stored first. Read-only credentials are enough for history access, not for full integration. See [Connecting a bank](https://docs.panoqore.com/connectors/connecting.md).

One switch can wait for approval at a time for each bank. The change is checked again when it is approved, and recorded as a `partner.mode_changed` event.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.