Limits
Freshness and the read interval
Accounts are read from the bank at intervals; the data is not real time. The shortest time between two reads differs per connection and is given in each account's freshness.minSyncIntervalSeconds field. Do not assume a fixed duration in your code; read this field.
For a transaction to appear in the API and the webhook after money lands in your account, two things are needed: the bank reporting the transaction and the account's next read. You can see when a transaction was recorded in the receivedAt field. → Concepts › Freshness
Sync Now does not shorten the read interval; if the interval has not elapsed, the read is scheduled for nextSyncAvailableAt.
Sync now request limit
| Endpoint | Limit | Scope |
|---|---|---|
POST /api/v1/bank-connect/accounts/{accountId}/sync | 6 requests per minute | Per API key |
When the limit is exceeded, the request returns 429 RATE_LIMITED. The response's Retry-After header and details.retryAfterSeconds field give the number of seconds to wait; respect it. Read endpoints (GET) do not count towards this limit. → Rate Limits
The limit is separate from the read interval. Even below the limit, reads do not happen more often than minSyncIntervalSeconds; sending repeated requests for the same account brings no benefit.
Money transfer and exchange limits
| Endpoint | Limit | Scope |
|---|---|---|
POST /api/v1/bank-connect/transfers, POST /api/v1/bank-connect/fx/quotes, POST /api/v1/bank-connect/fx/orders | 20 requests per minute, the three together | Per API key |
When the limit is exceeded, the request returns 429 RATE_LIMITED; the Retry-After header and the details.retryAfterSeconds field tell you how many seconds to wait. Read endpoints (GET) do not count toward this limit. This is Lunixi's application limit; it does not replace your bank's transfer and exchange limits. When a bank limit is exceeded, a transfer fails with result code bank_connect.transfer.limit_exceeded, an exchange order with bank_connect.fx.limit_exceeded.
In the panel the same operations are limited per user:
| Panel operation | Limit |
|---|---|
| Starting a transfer, exchange quote and order | 20 per minute per user |
| Confirming the verification code and asking for a new code | 10 per minute per user |
| New verification code | At least 30 seconds apart, at most 5 times per operation |
Transfer and exchange rules
| Rule | Value |
|---|---|
| Transfer currency | Only TRY today |
| Receiver name | 2–140 characters |
| Description | At most 140 characters |
Idempotency-Key | 8–200 printable ASCII characters |
| Amount | An integer greater than zero, in minor units. The bank sets the per-transaction limit. |
| Balance | Not checked by Lunixi; the bank decides. |
| Panel transfer waiting for confirmation | Canceled if the code is not confirmed within 10 minutes. |
| Panel exchange session | 5 minutes after the code is confirmed; not extended. |
| Exchange quote | The short validity the bank sets (expiresAt, validForSeconds); usually a minute or two. |
| API key IP allowlist | Single IP addresses, at most 50; ranges (CIDR) are not accepted. |
Transaction queries
| Limit | Value |
|---|---|
bookedFrom–bookedTo range | At most 92 days per request |
| Without a date filter | No limit; all transactions are paginated |
Accounts in the accountId filter | At most 100 |
To read a longer period, split it into 92-day chunks or paginate without a date filter. → Transactions
Retention
Transactions that have been read are retained indefinitely; you can access past transactions at any time through the API and the panel.
Page size
| Parameter | Value |
|---|---|
limit | 1–100, default 25. Above 100 returns 400. |
pageInfo.totalCount | Always null on these endpoints. |
If you read many records, use limit=100; you send four times fewer requests for the same data.