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

# Operation types and the ledger

> What wede does with each accepted event: send a team, record an operation in the ledger, or keep a record

Every event type of your [catalog](/api-reference/event-types.md) says what wede does once an event of that type is accepted, online or synchronised after an outage. There are three ways, and each event takes exactly one.

| Execution | What wede does | Typical types |
| - | - | - |
| `dispatch` | Chooses and sends a team, and follows the mission to the end | Cardiac arrest, fire, field repair. Always the case for a type that needs teams |
| `ledger` | Writes one immutable line in the operation ledger, with the amount, currency, direction and reference as captured | Payments, withdrawals, deposits, reversals, equipment readings |
| `record` | Keeps the event and delivers it to your systems, with nothing else to do | Triage notes, status reports, sensor events |

A type that needs teams is always `dispatch`. For the others you choose `ledger` or `record` in the catalog (`execution` in `POST /v1/catalog/types`); `record` is the default. Changing the execution of a type applies to the events accepted from then on.

## The operation ledger

Each event of a `ledger` type becomes one line, once, whatever the channel it came through and however many times it was sent. The line is never changed or removed afterwards. It keeps:

* the operation code (the type), the vertical and the environment;
* the amount in minor units of its currency, with the decimals of that currency (none for JPY, three for KWD), or the quantity and unit as captured;
* the direction: `in`, `out` or `neutral`;
* your reference (for example the RRN of a card payment), which is what your own records are later checked against;
* whether it was captured online or offline, the time of capture on the device and the time it reached wede;
* the device that captured it, when the event says which one. See [Devices](/concepts/devices.md).

wede takes these values from the payload as captured. Send `amount_minor` (or `amount` with its `currency`), `direction` and one reference field such as `tx_ref`, `reference` or `rrn`. When the direction is not sent, it follows the operation code: a withdrawal or a refund is `out`, a deposit or a payment is `in`.

> [!NOTE]
>
> wede applies no value limit, no eligibility rule and no approval to an operation. Those are rules of your organisation and of its partners and stay with them. wede carries each operation once, keeps it whole and shows whether your records agree. See [Continuity, not connectivity](/concepts/continuity.md).

## Reading the ledger

```bash theme={null}
curl "https://api.wede.pt/v1/ledger?code=payment_offline&origin=offline&from=2026-10-01T00:00:00Z" \
  -H "X-Wede-API-Key: $WEDE_API_KEY"
```

The answer lists the operations, newest first, 50 per page by default (up to 200), and the count and total amount per direction for the whole filter, not just the page. Filters: `from`, `to`, `code`, `direction`, `origin` (`online` or `offline`) and `reversal` (`linked` or `unlinked`). Reading the ledger needs `events:read`; the wede team never sees your amounts.

A reversal is an operation of its own, tied to the operation it reverses when it carries the original reference. The ledger shows both sides: `reversal_of` on the reversal and `reversed_by` on the original.

## From the ledger to your books

The ledger is one side of the books. The other side is your own records: a bank statement, an ATM journal, a terminal counter. wede checks each of your records against the ledger and shows what matched, what differs, what is still waiting and what was never confirmed. See [Reconciliation](/concepts/reconciliation.md).

The SDKs (2.6.0 and later) read the ledger and send your records in batches of any size:

| SDK | Methods |
| - | - |
| JavaScript and React Native | `listLedger`, `createReconciliationSource`, `sendReconciliationRecords`, `getReconciliationGrid`, `listReconciliationOperations` and the rest |
| Python | `list_ledger`, `create_reconciliation_source`, `send_reconciliation_records`, `get_reconciliation_grid`, `list_reconciliation_operations` and the rest |
| Android (Kotlin) and Swift | `listLedger`, `createReconciliationSource`, `sendReconciliationRecords`, `getReconciliationGrid`, `listReconciliationOperations` and the rest |

Sending records and creating sources belong on your server, with the API key. An app of a signed-in user can read the results when its role sees reconciliation.


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