CAcardda
Bank transaction

Get transfer limit

Changed on

Answers the per-transfer cap that applies to a transfer you are about to create, so you can size the amount (or ask the API to split it, see split on createBankTransaction) before you send anything.

The cap is not a property of a bank alone: it depends on the sending bank, the destination bank (same-bank transfers are never capped), whether the transfer belongs to an online or a deferred payroll, and the LBTR flag. Rather than reimplementing those four rules — and drifting from them — ask here.

The answer does not depend on the amount, so it is cacheable — but the caller is part of the key: (caller, sender_id, recipient_id, bank_payroll_id, lbtr). Both recipient_id and bank_payroll_id are resolved through the calling user's own visibility, so the same tuple is a 404 for a caller who cannot see them and a cap for one who can. Cache it private / per-session only — never in a shared or proxy cache, which would hand the second answer to the first.

It resolves a cap, it does not validate the transfer

This endpoint answers only "how large may one transfer be". It does not run the validations of createBankTransaction, so a 200 here is not a promise that the transfer is creatable — in particular for lbtr:

  • lbtr: true between two accounts of the same bank answers max_amount: null (same-bank is uncapped), but creating it is a 422 "Lbtr cannot create lbtr transaction if the sender and recipient belong to the same bank".
  • lbtr: true out of a bank other than Banco de Chile or Santander answers that bank's ordinary cap (LBTR does not lift it there), and creating it is a 422 "Lbtr is not yet implemented at bank {bank_id}".

The rest of the create-time rules (recipient approved, description format, budget, payroll state) are likewise out of scope here; they are listed on the 422 of createBankTransaction.

get/v1/banking/bank_transactions/transfer_limit

Request

Query parameters

sender_idstring uuid required

The account the transfer would leave from. Must be an account you are a user of — that is the guard, not bank-key reachability: unlike createBankTransaction, this endpoint resolves no bank key. An account you are not a user of is 401; an id that matches no account at all is 404.

recipient_idstring uuid required

The recipient the transfer would go to, enrolled in sender_id (GET /v1/banking/bank_recipients?owner_id={sender_id}). A recipient of another account answers 404.

bank_payroll_idstring uuid

The payroll the transfer would join, if any. It matters: at Banco de Chile and BICE a deferred payroll (online: false) has no cap, while an online one keeps it. At Banco Security the cap is flat and the payroll changes nothing.

Must be a payroll of sender_id (payrolls belong to one sending account), otherwise 404 — including a payroll of another of your own accounts, which you can see but this transfer could not join. Omitting the parameter is a different question ("no payroll") and answers the no-payroll cap; it is never treated as a missing record.

lbtrboolean

Whether the transfer would be sent as LBTR (Chile's RTGS), which lifts the cap where supported (Banco de Chile and Santander). Anywhere else the cap comes back unchanged and the transfer itself would be rejected at creation — this endpoint does not check that.

Parameters

#/paths/~1v1~1banking~1bank_keys/get/parameters/0 (unresolved $ref)

Response

The cap in force for that transfer

max_amountinteger nullable required

Maximum amount of a single transfer, in the minor unit of the sending account's currency (CLP has no subunit — 7000000 is $7.000.000). null means the transfer has no cap: same-bank, LBTR, or a deferred payroll at a bank that lifts it. It does not mean the transfer is creatable — see "It resolves a cap, it does not validate the transfer".

max_transactionsinteger required

How many rows one split: true request may create. An amount that would need more is rejected with 422 and nothing is created.

Always present and never null. It is a server-side constant, not a per-transfer computation: every 200 carries it, including the uncapped max_amount: null case. Unlike max_amount, it does not depend on the sender, the recipient, the payroll or lbtr. Model it as a required non-nullable integer — a client that treats it as optional and falls back to a hardcoded default is carrying a second, silently diverging copy of this limit. The value may change between releases, so read it from here instead of hardcoding 120.

Example response

{
  "max_amount": 7000000,
  "max_transactions": 120
}

Changes