Transactions

A transaction is a single line of the account statement. These endpoints return the transactions of your connected accounts. Transaction direction and types: Concepts › Transaction direction and type.

List transactions

GET /api/v1/bank-connect/transactions

Date range rules

• The range between bookedFrom and bookedTo can be at most 92 days in a single request.
• If you send only bookedFrom, the upper bound is the time of the request; the range is still at most 92 days.
• bookedTo cannot be sent alone; bookedFrom is also required.
• If you send neither, no date filter is applied and all transactions are paginated.

A request that breaks these rules returns 400 bank_connect.validation.invalid; the reason is in details.errors[].reason:

Filter examples

There is no filter that searches the description text; any undeclared parameter returns 400 VALIDATION_ERROR.

source lunixi-sign.sh
REQ_PATH="/api/v1/bank-connect/transactions?direction=CREDIT&canonicalType=TRANSFER_IN&limit=50"
lunixi_sign GET "$REQ_PATH"
 
curl "https://api-gateway.lunixi.com$REQ_PATH" \
  -H "X-Key-Id: $LUNIXI_KEY_ID" \
  -H "X-Date: $DATE" \
  -H "X-Nonce: $NONCE" \
  -H "X-Signature: $SIGNATURE"

$bankConnect in the PHP example: API Introduction › PHP SDK.

Ordering

Transactions are ordered by the time they were recorded (receivedAt), newest first. receivedAt is the moment the transaction was read from the bank and recorded at Lunixi, and it never changes. The booking date (bookedAt) is only a filter, not the sort key.

So if a bank reports a transaction late, it appears at the top of the list even though its booking date is older.

Response

{
  "status": "success",
  "code": "SUCCESS",
  "data": {
    "items": [
      {
        "transactionId": "00000000-0000-0000-0000-000000001000",
        "accountId": "00000000-0000-0000-0000-000000000100",
        "direction": "CREDIT",
        "amountMinor": 150000,
        "currency": "TRY",
        "bookedAt": "2026-01-01T07:00:00.000Z",
        "canonicalType": "TRANSFER_IN",
        "description": "ORNEK ACIKLAMA",
        "counterpartyNameMasked": "Ö**** A****",
        "counterpartyIbanMasked": "TR00 **** **** **** **** **00 00",
        "receivedAt": "2026-01-01T07:05:00.000Z"
      }
    ]
  },
  "pageInfo": { "hasMore": true, "nextCursor": "eyJ0IjoiMjAyNi0wMS0wMVQwNzowNTowMFoifQ", "totalCount": null },
  "statusCode": 200,
  "requestId": "00000000-0000-0000-0000-000000000000"
}

Single transaction

GET /api/v1/bank-connect/transactions/{transactionId} returns a single transaction. In addition to the list fields, it contains the balance after the transaction, the document number and the bank. A transaction that is unknown, belongs to another organization or to the other environment returns 404 bank_connect.transaction.not_found.

{
  "status": "success",
  "code": "SUCCESS",
  "data": {
    "transactionId": "00000000-0000-0000-0000-000000001000",
    "accountId": "00000000-0000-0000-0000-000000000100",
    "direction": "CREDIT",
    "amountMinor": 150000,
    "currency": "TRY",
    "bookedAt": "2026-01-01T07:00:00.000Z",
    "canonicalType": "TRANSFER_IN",
    "description": "ORNEK ACIKLAMA",
    "counterpartyNameMasked": "Ö**** A****",
    "counterpartyIbanMasked": "TR00 **** **** **** **** **00 00",
    "receivedAt": "2026-01-01T07:05:00.000Z",
    "counterpartyBankCode": "0000",
    "counterpartyBankName": "ÖRNEK BANKA",
    "balanceAfterMinor": 990000,
    "documentNo": "0000000",
    "bank": { "bankId": "00000000-0000-0000-0000-000000000001", "eftCode": "0000", "name": "ÖRNEK BANKA" }
  },
  "statusCode": 200,
  "requestId": "00000000-0000-0000-0000-000000000000"
}

The transaction object

Keeping transactions in sync

The primary way to learn about new transactions is the webhook event. The list endpoint is the reliable source when you missed a webhook or pull data for the first time. Use them together like this:

1. Initial load. Request the first page without filters (or only with accountId) and paginate with nextCursor until pageInfo.hasMore is false. Store each transaction by transactionId and keep the newest receivedAt you have seen.
2. Regular catch-up. At intervals, start from the first page (no cursor) with the same filters. Because the list is newest first, paginate until you pass behind the newest receivedAt you stored, then stop.
3. Deduplicate. Put the stop point a little behind the receivedAt you stored and deduplicate every incoming transaction by transactionId; receiving the same transaction from both the webhook and the list is then harmless.

When you change filters, reset the cursor and start from the first page.

Errors