Skip to main content

Get the evaluation report (informe)

GET 
/partner/pre-approve/:preApproveId/informe

Returns a short-lived download link to the PDF report for a pre-approval, given your API token and the pre-approval id.

The report is not returned in the response body. The response carries a url, and the PDF is fetched with a second, plain GET against that URL.

There are two ways to reach the same report​

This is the server-to-server one. The other is Open the evaluation report from its link, which takes no token and redirects straight to the download — that is what the urlInforme field of the event and of the evaluation reads points at.

This endpointOpen the report from its link
Path parameterpreApproveId, i.e. idPreAprobacionsignature, received in urlInforme
API tokenRequiredNot accepted
Answers200 with { "data": { "url": ... } }302 to the signed link
Good forserver-to-server fetchessharing, embedding, pasting

Neither replaces the other, and both serve the identical document. Use this one when you are already authenticated and want the link as data — for example, when all you have is an idPreAprobacion from List leads, whose rows do not carry urlInforme.

The url is a pre-signed link. It already carries its own credentials, so the second request must be a bare GET — do not send your Authorization header to it. Adding one causes the storage layer to reject the request.

Store the id — never the signed link​

Two different URLs are involved and neither is the thing to persist:

ValueLifetimeStore it?
idPreAprobacionPermanent — it is an idYes
This endpoint's addressPermanent — it is a routeYes, or rebuild it from the id
The url it returns1800 secondsNever

The signed link is issued fresh on every call and is only good for 30 minutes — treat it as something you redirect to or fetch immediately, never as something you write to a database or paste into an email. To serve the report again later, call this endpoint again.

The signed link forces a download named PreAprobacion_<preApproveId>.pdf.

Where preApproveId comes from​

It is the id of the pre-approval, not of the lead. Passing a preLoanRequestId here is the natural mistake and will not work.

Every path that tells you about a lead hands you this id as idPreAprobacion:

SourceFields
The pre_approve webhook eventidPreAprobacion · urlInforme
Get an evaluation by lead ididPreAprobacion · urlInforme
Get the latest evaluation by RUTidPreAprobacion · urlInforme
List leads — every rowidPreAprobacion only

Get lead details is the one read that carries neither, by design.

Push and pull give you the same report​

Whether you were notified or you asked, you end up at the same place — which means you do not need to store the report, only the lead:

# Push: the event arrives
{ "eventId": "...", "data": { "idPreAprobacion": "a91f3d70-...", ... } }

# Pull: you ask, at any later time
GET /partner/pre-approve/rut/12345678-9
→ { "data": { "idPreAprobacion": "a91f3d70-...", ... } }

# Either way, the same call
GET /partner/pre-approve/a91f3d70-.../informe
→ { "data": { "url": "https://...&X-Amz-Expires=1800..." } }

If you missed the webhook, the read endpoints recover the same identifier.

When the PDF is re-rendered​

banca.me stores a fingerprint of the data each report was built from and compares it on every call. The trigger is a change in content, not the age of the stored file. Two consequences worth knowing:

  • A change in any input — the risk parameters, your partner name — produces a new PDF, even if the stored copy is newer than the pre-approval itself.
  • Re-saving without changing the data re-serves the existing copy; it does not re-render.

Either way you call the same endpoint and get a fresh signed link.

Request​

Responses​

Download link issued successfully