Event Catalog

banca.me emits five webhook events. This page documents every field each one carries.

Event	Belongs to	Fires when	Registered through
`loan_approved`	BNPL partners	A BNPL loan is approved	`POST /partner/webhook`
`new_lead`	Real-estate partners	A lead is created, before any evaluation	`POST /partner/webhook/subscription`
`pre_approve`	Real-estate partners	That lead's evaluation completes	`POST /partner/webhook/subscription`
`reevaluation`	Real-estate partners	You re-evaluate a lead and a new re-evaluation finishes	`POST /partner/webhook/subscription`
`installment_paid`	Mortgage lenders	banca.me collects an installment of one of your loans	`POST /partner/webhook/subscription`

If you are not sure which side you are on, start at Which Webhook Integration Is Yours. For the envelope all five travel in, see Webhook Event Format. Verification differs by integration: HMAC for BNPL, token for real estate and mortgage lenders.

Choosing events, filtering and scoping is a real-estate feature. On the subscription route you pick which events a destination receives, filter pre_approve by outcome — for example to receive only aprobado — and narrow a destination to a single project. The BNPL route has no equivalent; it always registers a plain loan_approved destination.

A result filter only narrows events that have a result

new_lead fires before any evaluation, so it has no outcome to filter on. A destination subscribed to both events with filters.results set receives every new_lead regardless — the filter applies to pre_approve alone.

This surprises people: narrowing to aprobado does not reduce new_lead traffic at all. If you want a low-volume feed, subscribe a destination to pre_approve only.

The same goes for reevaluation: the filter never applies to it, and a subscribed destination receives every re-evaluation, whatever its result.

Delivery guarantees are not the same for every event

new_lead runs on a tighter budget than the others — 3-second timeout and no retry, because it fires inside a form submission. installment_paid is the opposite: after its retry, banca.me sends it again every night until your endpoint answers 2xx. See Best Practices.

Telling the events apart

Every event except loan_approved carries an eventType field. The body is { eventId, eventType, data } for new_lead, pre_approve, reevaluation and installment_paid, and { eventId, data } — no eventType — for loan_approved:

{
  "eventId": "9f2a1c4e-3b8d-4f71-a205-6c9e8d0b1a37",
  "eventType": "pre_approve",
  "data": { }
}

This only matters if one endpoint is subscribed to more than one event — which, since the real-estate events go to the same route, is a realistic setup. Read eventType directly instead of sniffing data:

Event	`eventType`
`loan_approved`	not present — see why
`new_lead`	`"new_lead"`
`pre_approve`	`"pre_approve"`
`reevaluation`	`"reevaluation"`
`installment_paid`	`"installment_paid"`

If you built a discriminator before eventType existed, it still works — new_lead and pre_approve share eleven identity fields, so data.idBancame alone does not separate them; you need a field that only the evaluation carries, such as estado or fechaEvaluacion. eventType is additive, not a replacement, so nothing that already worked stops working.

An alternative some partners prefer regardless of eventType: register one destination per event type. Each destination has its own URL, so the URL alone tells you which event arrived.

`loan_approved` — BNPL

The BNPL event. Fires when a BNPL loan is approved; receiving it is itself the confirmation that the loan was approved — there is no status to check to find that out.

Destinations for this event are registered through POST /partner/webhook and verify by HMAC signature.

Fields

Field	Type	Description
`externalTrxId`	string	External transaction identifier — your own reference for the purchase
`loanAmount`	number	Total amount of the loan
`interestRate`	number	Interest rate, as a percentage rounded to two decimals — `1.5` means 1.5%
`periods`	number	Number of instalments
`installmentAmount`	number	Amount of each instalment
`lastInstallmentAmount`	number	Amount of the final instalment, which may differ from the rest
`state`	string	State of the loan. Always `ACTIVE` in this event — see below
`transferDate`	string	ISO 8601 date the loan was funded
`installments`	array	The payment schedule

Each entry of installments carries:

Field	Type	Description
`state`	string	State of that instalment
`period`	number	Instalment number, starting at 1
`expirationDate`	string	ISO 8601 date the payment is due

Loan states

loan_approved is sent once, when the loan is approved, and is not sent again when the loan changes later. The loan's state is therefore always ACTIVE; the event does not track the loan afterwards.

Each entry of installments carries its own state, using these names:

ACTIVE — active loan
PARTIAL_PREPAID — partially prepaid
PREPAID — fully prepaid
PAID — fully paid
REFINANCED — refinanced
SOFT_DEBT — overdue, 1 to 30 days
INTERMEDIATE_DEBT — overdue, 31 to 89 days
HARD_DEBT — overdue, 90+ days
RECOVERED — recovered
PUNISHED — written off
OUTSOURCED — outsourced
CANCELED — canceled
PARTIAL_REFUND_REPLACED, PARTIAL_REFUND_SETTLED — states used by partial refunds

Receiving the webhook already tells you the loan was approved, so there is no need to inspect state to confirm that.

Example

{
  "eventId": "6b1d4f2a-9c37-4e85-a0d6-2f8e3c5b7a91",
  "data": {
    "externalTrxId": "txr_abc123def456",
    "loanAmount": 500000,
    "interestRate": 1.5,
    "periods": 3,
    "installmentAmount": 170000,
    "lastInstallmentAmount": 170000,
    "state": "ACTIVE",
    "transferDate": "2023-09-15T15:10:33.000Z",
    "installments": [
      { "state": "ACTIVE", "period": 1, "expirationDate": "2023-10-15T00:00:00.000Z" },
      { "state": "ACTIVE", "period": 2, "expirationDate": "2023-11-15T00:00:00.000Z" },
      { "state": "ACTIVE", "period": 3, "expirationDate": "2023-12-15T00:00:00.000Z" }
    ]
  }
}

Handling it

function processLoanEvent(event) {
  const { eventId, data } = event;

  updateLoanStatus(data.externalTrxId, data.state);

  const schedule = data.installments.map((inst) => ({
    number: inst.period,
    amount:
      inst.period === data.periods
        ? data.lastInstallmentAmount
        : data.installmentAmount,
    dueDate: new Date(inst.expirationDate),
    status: inst.state,
  }));

  savePaymentSchedule(data.externalTrxId, schedule);
}

`new_lead` — Real estate

Fires the moment a lead is created, before any evaluation has run. It is the first thing you hear about a person.

Registered through POST /partner/webhook/subscription, verifies by token, and requires the evaluation module.

Order matters when you read this against the funnel

new_lead arrives before pre_approve, not after. A lead that abandons the flow before finishing still generated its new_lead — so this event counts arrivals, not qualified leads, and the two will not reconcile. Expect new_lead volume to exceed pre_approve volume.

Fields

Twelve fields, all identity and contact. Eleven of them are byte-for-byte the same as the identity block of pre_approve and come from the same code, so you can map both events with one function. The only difference is fechaCreacion here versus fechaEvaluacion there.

Field	Type	Description
`idBancame`	string	The lead's identifier in banca.me. The `preLoanRequestId` the read endpoints take
`nombre`	string	Given name
`apellidoPaterno`	string	First surname
`apellidoMaterno`	string	Second surname
`rut`	string	National identifier
`telefono`	string \| null	Phone number
`email`	string \| null	Email address
`origen`	string	Where the lead came from (QR, web, bot, ...)
`proyecto`	string \| null	Name of the PartnerEntity the lead belongs to — the readable one
`proyectoIdExterno`	string \| null	The external id you assigned to that PartnerEntity. This is the homologation key
`fechaCreacion`	string	When the lead was created, ISO 8601
`linkBancame`	string	The lead's page in the banca.me portal

No financial data, by design

new_lead carries no risk parameters and no outcome fields — not because they were left out, but because nothing has been evaluated yet when it fires. There is nothing to send. Those fields arrive later, in pre_approve, for the same lead.

Example

{
  "eventId": "4c7e2a91-6d35-4b80-9f12-3a8c5e7d0b24",
  "eventType": "new_lead",
  "data": {
    "idBancame": "3f1a9c2e-8b47-4d51-9e6a-2c7d0b5f8a13",
    "nombre": "María",
    "apellidoPaterno": "González",
    "apellidoMaterno": "Pérez",
    "rut": "12345678-9",
    "telefono": "+56912345678",
    "email": "maria.gonzalez@example.com",
    "origen": "inmobiliaria-qr",
    "proyecto": "Condominio Los Robles",
    "proyectoIdExterno": "ex-test-123",
    "fechaCreacion": "2026-09-01T14:05:11.000Z",
    "linkBancame": "https://partners.banca.me/leads/id/3f1a9c2e-8b47-4d51-9e6a-2c7d0b5f8a13"
  }
}

Correlate it with the pre_approve that follows using idBancame: both events carry the same value for the same lead.

`pre_approve` — Real estate

Fires when a lead's risk evaluation completes and produces an outcome — after the new_lead for that same person.

Destinations for this event are registered through POST /partner/webhook/subscription, verify by token, and require the evaluation module. BNPL partners cannot subscribe to it.

The outcome fields are binary — complementable is not one of their values

estado, resultadoHipotecario and resultadoPie are derived from whether the pre-approval was accepted, so each is either aprobado or rechazado and nothing else.

A lead that does not qualify alone but would with an income co-applicant reads estado: "rechazado" together with complementable: true. Read the boolean — branching on estado === "complementable" will never match.

The three-value set aprobado | complementable | rechazado is real, but it belongs to the delivery filters you set when registering a destination, which is a different dimension from the payload fields.

Applying a complement does not send a new pre_approve

When an income co-applicant complements a lead, banca.me re-evaluates the lead with both incomes combined — the lead can go from rejected to approved — but no new pre_approve is sent for the lead. The last pre_approve you received for it keeps saying rechazado.

What you do receive is the co-applicant's own new_lead and pre_approve: the co-applicant is a lead in its own right, and those events describe their evaluation alone, with nothing marking them as a complement.

To learn the combined result, read it from the API: GET /partner/pre-loan-request/{idNumber} for the lead's RUT returns the complemented pre-approve, carrying the co-applicant's lead id in complementaryPreLoanRequestId. You can try the whole flow in automation — see Complement a lead.

note

There is no "evaluation started" event. The webhook fires when the evaluation finishes; while one is in progress there is nothing to send.

data is a flat object in camelCase — no nesting. The groups below are documentation only; they are not levels in the JSON.

The read API returns the same data in a different shape

The evaluation read endpoints return this same evaluation nested, with hipotecario and pie as sibling blocks, because their consumer is a UI rather than a CRM field mapping. If you consume both the event and the API, expect two shapes of the same data. The correspondence is noted per field below.

Identification and contact

Field	Type	Description
`idBancame`	string	The lead's identifier in banca.me. This is the `preLoanRequestId` the read endpoints take.
`nombre`	string	Given name
`apellidoPaterno`	string	First surname
`apellidoMaterno`	string	Second surname
`rut`	string	National identifier
`telefono`	string \| null	Phone number
`email`	string \| null	Email address

Origin and context

Field	Type	Description
`origen`	string	Where the lead came from (QR, web, bot, ...)
`proyecto`	string \| null	Name of the PartnerEntity the lead belongs to — the readable one
`proyectoIdExterno`	string \| null	The external id you assigned to that PartnerEntity. This is the homologation key
`fechaEvaluacion`	string	When the evaluation ran, ISO 8601
`vigenteHasta`	string \| null	Validity date of the mortgage pre-approval, ISO 8601: 28 days after it was issued. `null` when there is no mortgage pre-approval

Outcome

Field	Type	Description
`estado`	string \| null	Outcome of the mortgage pre-approval, always equal to `resultadoHipotecario`. Binary: `aprobado` or `rechazado` only. `null` when there is no mortgage pre-approval
`complementable`	boolean \| null	Whether the lead qualifies with an income co-applicant. This is where "complementable" lives — not in `estado`
`idComplementario`	string \| null	Reserved for the co-applicant's lead id. The evaluation this event reports is always the applicant's own, without a co-applicant, so it arrives `null`
`grupoSocioeconomico`	string \| null	Net-income bracket, as a display label derived from `sueldoLiquido` — for example `"Desde de $1.500.000 hasta $2.500.000"` or `"Más de $5.500.000"`. Not a letter code

Credit terms

These describe the mortgage product. resultadoPie is the only down-payment field in the event; the read API returns the down payment as a full sibling block.

Field	Type	Description
`resultadoHipotecario`	string \| null	Mortgage outcome. Binary (`aprobado` / `rechazado`). Equivalent to `hipotecario.resultado` in the read API
`resultadoPie`	string \| null	Down-payment outcome. Binary. Equivalent to `pie.resultado`
`subproducto`	string \| null	Sub-product evaluated. Equivalent to `hipotecario.subproducto`
`montoAprobado`	string \| null	Approved amount in UF, pre-formatted for display — e.g. `"262.00 UF"`. It is a string and it is not pesos; the same figure as a number is `montoAprobadoUf`
`montoAprobadoUf`	number \| null	Approved amount in UF. Equivalent to `hipotecario.montoMaximoUf`
`plazoHipotecario`	number \| null	Maximum term, in months. Equivalent to `hipotecario.plazoMaximo`
`tasa`	number \| null	Interest rate, as a decimal. Equivalent to `hipotecario.interes`
`dividendoMaximo`	number \| null	Maximum monthly instalment, in the product's own currency. The read API's `hipotecario.dividendoMaximoUf` is the same figure converted to UF — the two are not interchangeable
`causaRechazo`	string[]	Rejection reasons. Empty array when the lead was not rejected

Report and links

Field	Type	Description
`idPreAprobacion`	string \| null	The pre-approval id, and the stable half of this pair. Pass it to Get the evaluation report
`urlInforme`	string \| null	Link that opens the PDF report. Takes no API token — see Open the evaluation report from its link
`linkBancame`	string	The lead's page in the banca.me portal

urlInforme and linkBancame are not interchangeable

urlInforme opens the report, and it takes no token: a plain GET with no headers answers a redirect to the PDF. That is why it works pasted into a browser, stored in a CRM field, or put behind a "view report" button in your own platform.

linkBancame opens the lead's page in our portal, and it prompts for a banca.me login.

Do not send your Authorization header to urlInforme. If you would rather stay server to server, Get the evaluation report takes your token and idPreAprobacion and returns the download link as JSON.

urlInforme is a credential, and it does not expire

The report carries the lead's personal data, so anyone holding the link can read it. It cannot be revoked once shared — keep it inside systems you control, and think twice before putting it in a forwardable email.

It is also new on every read: each read mints a fresh signature, so two consecutive calls for the same lead give different urlInforme values that open the same report, and older links keep working. If you diff payloads to detect changes, or cache by URL, key on idPreAprobacion instead — that one is stable.

And it can arrive null while idPreAprobacion is not. Minting the signature is a call to our key service; if that call fails we still deliver the event, with this field null, rather than dropping it over one link. Read null here as "no link this time", not as "no report" — Get the evaluation report still reaches the document with idPreAprobacion.

Financial profile

The evaluation's underlying risk parameters. Every field in this group is optional: a parameter that was not computed for a given lead is omitted from the object rather than sent as null.

Sensitive personal data

This group is sensitive financial data about an individual, and every destination subscribed to pre_approve receives it. The payload is built once per event and delivered as-is to each destination — there is no per-destination setting that omits these fields.

Plan for that when choosing where pre_approve is delivered: if a destination only needs to create an opportunity in a CRM and alert an executive, it will still receive the full financial profile. Treat every pre_approve endpoint as handling sensitive personal data.

Field	Type	Description
`edad`	number	Age, in years
`sexo`	string	Sex, as declared
`sueldoBruto`	number	Gross monthly salary
`sueldoLiquido`	number	Net monthly salary
`tipoTrabajador`	string	Worker type
`tipoContrato`	string	Contract type
`antiguedadLaboral`	number	Job tenure, in months
`lagunasPrevisionales`	number	Gaps in pension contributions
`esDuenoEmpresa`	boolean	Whether the lead owns a company
`protestos1Ano`	number	Protests and delinquencies over the last year
`protestos5Anos`	number	Protests and delinquencies over the last five years
`deudaCastigada`	number	Written-off debt
`deudaConsumo`	number	Consumer debt
`deudaComercial`	number	Commercial debt
`deudaHipotecaria`	number	Mortgage debt
`deudaMensual`	number	Total monthly debt service
`apalancamientoConsumo`	number	Consumer-debt leverage
`apalancamientoTotal`	number	Total leverage
`cargaFinancieraTotal`	number	Total financial burden, over net salary
`cargaFinancieraConsumo`	number	Consumer financial burden, over net salary
`cargaFinancieraHipotecario`	number	Mortgage financial burden, over net salary
`cargaFinancieraSobreSueldoBruto`	number	Financial burden over gross salary
`deudorPensionAlimenticia`	boolean	Whether the lead is an alimony debtor
`fechaNacimiento`	string	Date of birth

banca.me never sends policy thresholds — the cut-off values a lead was measured against — and never sends its internal scoring. The read API additionally returns three policy results as booleans, in a resultadosPolitica block; those do not travel in the event.

Example

{
  "eventId": "9f2a1c4e-3b8d-4f71-a205-6c9e8d0b1a37",
  "eventType": "pre_approve",
  "data": {
    "idBancame": "3f1a9c2e-8b47-4d51-9e6a-2c7d0b5f8a13",
    "nombre": "María",
    "apellidoPaterno": "González",
    "apellidoMaterno": "Pérez",
    "rut": "12345678-9",
    "telefono": "+56912345678",
    "email": "maria.gonzalez@example.com",
    "origen": "inmobiliaria-qr",
    "proyecto": "Condominio Los Robles",
    "proyectoIdExterno": "ex-test-123",
    "fechaEvaluacion": "2026-09-01T14:22:07.000Z",
    "vigenteHasta": "2026-09-29T14:22:07.000Z",
    "estado": "aprobado",
    "complementable": false,
    "idComplementario": null,
    "grupoSocioeconomico": "Desde de $1.500.000 hasta $2.500.000",
    "resultadoHipotecario": "aprobado",
    "resultadoPie": null,
    "subproducto": "main",
    "montoAprobado": "262.00 UF",
    "montoAprobadoUf": 262,
    "plazoHipotecario": 60,
    "tasa": 0.0,
    "dividendoMaximo": 585000,
    "causaRechazo": [],
    "idPreAprobacion": "a91f3d70-5c28-4e19-b6f2-84d7e0c1a5b9",
    "urlInforme": "https://api.banca.me/partner/pre-approve/AQICAHhQb1nQ2vJ0kK9rT7xYf3mN8pR4sL6wD1cE5aZ0uB2gXQFhVn7yKtM3pS9dG4jW6cR1/pdf",
    "linkBancame": "https://partners.banca.me/leads/id/3f1a9c2e-8b47-4d51-9e6a-2c7d0b5f8a13",
    "edad": 47,
    "sueldoLiquido": 1700000,
    "cargaFinancieraTotal": 0.105,
    "deudorPensionAlimenticia": false
  }
}

The data object above is truncated in the financial profile group for readability — a live payload carries every parameter that was computed for the lead.

`reevaluation` — Real estate

Fires when you re-evaluate a lead through POST /partner/lead/reevaluacion and a new re-evaluation finishes. It carries the same data the call answers with, without urlEvaluacion and reciente. What a re-evaluation measures is explained in Lead Re-evaluation.

Registered through POST /partner/webhook/subscription, verifies by token, and requires the evaluation module.

Sent for every new re-evaluation, whatever its result

An actualizado is sent too, and a destination's result filter does not apply. It is not sent when the call returns a recent re-evaluation (reciente: true) or ends in an error.

Deduplicate by idBancame

eventId is unique per destination and repeats on a retry, like in every event. If more than one destination receives reevaluation, or you also process the API response, use idBancame: each re-evaluation creates its own lead, and its id is the same everywhere.

Fields

The same names as pre_approve wherever the meaning is the same.

Field	Type	Description
`idBancame`	string	The new lead this re-evaluation created. The same field `new_lead` and `pre_approve` carry
`rut`	string	National identifier
`origen`	string	The lead's origin, the same as the person's earlier lead
`proyecto`	string \| null	Name of the lead's PartnerEntity
`proyectoIdExterno`	string \| null	The external id you assigned to that PartnerEntity
`fechaEvaluacion`	string	When the re-evaluation finished, ISO 8601
`estado`	string	`actualizado`, `a_revisar` or `rechazado`. See the three results
`estadoUltimoPreAprobacion`	string	How the person's last mortgage pre-approval with you stood — the one that was re-evaluated: `aprobado` or `rechazado`. An `actualizado` over a `rechazado` pre-approval is not an approval
`empeoro`	array	What worsened since the last evaluation, one entry per field. Empty when nothing did
`causaRechazo`	string[]	Policy filters the person fails today, with the same labels as in `pre_approve`. Never the thresholds. Empty unless `estado` is `rechazado`
`linkBancame`	string	The new lead's page in the banca.me portal. Prompts for a banca.me login
`riesgo`	object	The person's risk data after the re-evaluation

Each entry of empeoro:

Field	Type	Description
`campo`	string	The field that worsened, named as in `riesgo`: `protestos1Ano`, `protestos5Anos`, `deudaCastigada`, `deudaConsumo`, `deudaComercial`, `deudaHipotecaria`, `deudaMensual`, `cargaFinancieraTotal` or `deudorPensionAlimenticia`
`anterior`	number \| boolean	The value at the last evaluation
`actual`	number \| boolean	The value now

Amounts are integer pesos, cargaFinancieraTotal is a ratio and deudorPensionAlimenticia a boolean.

riesgo has the same keys and plain values as the pre_approve financial profile, without fechaNacimiento, sexo and cargaFinancieraSobreSueldoBruto. A key without a value is omitted. Debts, protests, alimony status and age are refreshed as of fechaEvaluacion; salaries and employment data come from the person's last evaluation.

It carries no name, phone, email, date of birth, sex, approved amounts, policy thresholds or urlEvaluacion — the evaluation link travels only in the API response.

Example

{
  "eventId": "0b7d6c1e-9a52-4f0e-8d3b-2f4c9e1a7b60",
  "eventType": "reevaluation",
  "data": {
    "idBancame": "e2f4a6c8-3d5b-4e7f-a1c3-9b8d7f6e5d33",
    "rut": "12345678-9",
    "origen": "inmobiliaria-qr",
    "proyecto": "Condominio Los Robles",
    "proyectoIdExterno": "ex-test-123",
    "fechaEvaluacion": "2026-11-20T14:02:11.482Z",
    "estado": "rechazado",
    "estadoUltimoPreAprobacion": "aprobado",
    "empeoro": [
      { "campo": "protestos1Ano", "anterior": 0, "actual": 1176000 },
      { "campo": "protestos5Anos", "anterior": 0, "actual": 2026000 }
    ],
    "causaRechazo": ["Protestos y Morosidades a 1 año", "Protestos y morosidades 5 años"],
    "linkBancame": "https://partners.banca.me/leads/id/e2f4a6c8-3d5b-4e7f-a1c3-9b8d7f6e5d33",
    "riesgo": {
      "protestos1Ano": 1176000,
      "deudaConsumo": 1200000,
      "sueldoLiquido": 1450000,
      "cargaFinancieraTotal": 0.31
    }
  }
}

riesgo above is truncated for readability; a live payload carries every value that has one.

Delivery

Five-second timeout and one retry, like pre_approve. The delivery is attempted inside the re-evaluation call, so by the time the API answers, your destinations have been tried. A missed event is not replayed: the same result stays readable in the seguimiento field of GET /partner/pre-loan-request/{idNumber}.

`installment_paid` — Mortgage lenders

Fires when banca.me collects an installment of one of your loans. An installment counts as collected when it becomes paid, recovered, prepaid, partially prepaid or refinanced, whatever the way it was collected: an automatic charge, a Duemint payment, an invoice paid by the customer, a manual payment, a prepayment or a refinance.

Registered through POST /partner/webhook/subscription or from the partners portal (option «Cuota pagada»), and verifies by token. It needs no module and takes no filters. You can scope a destination to one project, like the other events of that route.

Only mortgage lenders can subscribe

A partner is a mortgage lender when at least one of its active projects has a credit policy where the lender signs the deed. Any other partner that asks for installment_paid gets 422 ERR_PARTNER_EVENT_TYPE_NOT_AVAILABLE_FOR_PRODUCT, and the partners portal shows «Cuota pagada» only to mortgage lenders.

Installments collected from 27 October 2026, 00:00 Chile time, are reported. A destination that you register later still receives every installment collected since then that it has not acknowledged, during the next nightly run.

Fields

Amounts are decimal strings in pesos, with no thousands separator — "37780", not 37780 or "37.780".

Field	Type	Description
`idCredito`	string	The loan's identifier in banca.me
`idCuota`	string	The installment's identifier in banca.me. Use it to deduplicate across destinations
`numeroCuota`	number	Installment number, starting at 1
`totalCuotas`	number	Number of installments of the loan
`fechaVencimiento`	string	Due date, `YYYY-MM-DD`
`estado`	string	How the installment was settled: `pagada`, `recuperada` (paid after it was written off), `prepagada`, `prepago_parcial` or `refinanciada`
`fechaPago`	string	When the installment was settled, ISO 8601 with time zone
`moneda`	string	Always `CLP`. Every amount of this event is in pesos
`montoCuota`	string	The installment amount, in pesos
`montoCuotaUf`	string \| null	The installment amount in UF, for a loan in UF. `null` for a loan in pesos
`valorUf`	string	The UF value of the day of `fechaPago`, in Chile's time zone. A reference only: it is not the rate that priced the payment
`fuenteMonto`	string	Where `montoCuota` comes from: `cobrado` or `programado` — see below
`montoMora`	string \| null	Late-payment interest collected for this installment. `null` when `fuenteMonto` is `programado`
`montoGastosCobranza`	string \| null	Collection fees collected for this installment. `null` when `fuenteMonto` is `programado`
`montoTotalCobrado`	string \| null	`montoCuota` + `montoMora` + `montoGastosCobranza`. `null` when `fuenteMonto` is `programado`
`medioPago`	string \| null	The payment provider, such as `fintoc`, `getnet` or `duemint`. `null` when unknown or for a manual payment
`idCargo`	string \| null	The provider's charge reference. `null` when unknown, for a manual payment, or for Duemint
`idEntidad`	string \| null	The external id you assigned to the loan's project — the same value as `proyectoIdExterno` in the lead events

fuenteMonto tells you whether the amount was collected

cobrado: banca.me collected the installment through a customer invoice. montoCuota is the amount charged for it, and the late-payment and collection-fee fields carry what was charged with it.

programado: there is no collected invoice line — a manual payment, a prepayment or a refinance. montoCuota is the scheduled amount, converted to pesos with the UF of the payment day for a loan in UF, and the three fee fields are null. For prepago_parcial this is the scheduled installment, not the part that was paid.

Example

{
  "eventId": "2d8b4c1f-7a63-5e09-b8d4-1c6f3a9e0b72",
  "eventType": "installment_paid",
  "data": {
    "idCredito": "8e3f1a2b-4c5d-4e6f-9a7b-0c1d2e3f4a5b",
    "idCuota": "1b2c3d4e-5f6a-4b7c-8d9e-0f1a2b3c4d5e",
    "numeroCuota": 3,
    "totalCuotas": 240,
    "fechaVencimiento": "2026-11-05",
    "estado": "pagada",
    "fechaPago": "2026-11-04T15:20:44.000-03:00",
    "moneda": "CLP",
    "montoCuota": "512340",
    "montoCuotaUf": "12.7542",
    "valorUf": "40171.12",
    "fuenteMonto": "cobrado",
    "montoMora": "0",
    "montoGastosCobranza": "0",
    "montoTotalCobrado": "512340",
    "medioPago": "fintoc",
    "idCargo": "pi_2b7c9d1e3f",
    "idEntidad": "proyecto-norte-01"
  }
}

Delivery

Five-second timeout and one retry when the installment is collected. If no attempt gets a 2xx, banca.me sends it again every night until your endpoint answers 2xx. This is the one event that is delivered again after its attempts run out.

eventId is stable. There is one eventId per installment and destination, and every send of that pair carries it: the first attempt, the retry and every nightly resend. Deduplicate on it.
The body is built at each send. A nightly resend can carry a later value, for example a late-payment line paid after the first attempt. Process the first delivery of an eventId and acknowledge the repeats.
A rejection stops the resends. An answer 4xx other than 408 and 429 counts as a rejection, and the nightly run does not send that installment to that destination again. Fix the cause, then save the destination again — edit it in the portal, or send POST /partner/webhook/subscription with the same URL. The next nightly run sends what the destination never acknowledged. A timeout, a network error, 408, 429 and 5xx are retried every night with no action from you.
Turning a destination off stops it. A destination that is inactive, or that no longer has the installment_paid subscription, receives nothing. If you turn it back on, the next nightly run sends what it never acknowledged.

Telling the events apart​

loan_approved — BNPL​

Fields​

Loan states​

Example​

Handling it​

new_lead — Real estate​

Fields​

Example​

pre_approve — Real estate​

Identification and contact​

Origin and context​

Outcome​

Credit terms​

Report and links​

Financial profile​

Example​

reevaluation — Real estate​

Fields​

Example​

Delivery​

installment_paid — Mortgage lenders​

Fields​

Example​

Delivery​

Telling the events apart

`loan_approved` — BNPL

Fields

Loan states

Example

Handling it

`new_lead` — Real estate

Fields

Example

`pre_approve` — Real estate

Identification and contact

Origin and context

Outcome

Credit terms

Report and links

Financial profile

Example

`reevaluation` — Real estate

Fields

Example

Delivery

`installment_paid` — Mortgage lenders

Fields

Example

Delivery