Open the evaluation report (informe) from its link

GET 
/partner/pre-approve/:signature/pdf

Redirects to the PDF report. This endpoint takes no API token.

This is the address that arrives as urlInforme in the pre_approve event and in the two evaluation reads. You do not assemble it — you receive it already built, and you open it.

Open it, do not call it

A plain GET with no headers answers 302 and a Location pointing at a pre-signed download link. Most HTTP clients follow the redirect for you; a browser just shows the PDF. So the link works anywhere a link works: pasted in a browser, stored in a CRM field, put behind a "view report" button in your own platform.

Do not send your Authorization header. It is not needed here, and the second hop — the pre-signed storage link — rejects requests that carry one.

Why there is no token on a document with personal data

The signature in the path is the credential, and it is a narrower one than your API token.

It is unguessable, and it is tamper-evident: banca.me re-checks the pre-approval it names against the stored record on every call, so editing the signature produces a 404, never a different document.

Getting one still requires a token. You either called an authenticated read, or you received it in a webhook whose destination only an authenticated partner could register. What changes is the blast radius if a link leaks: a signature opens one report, while your API token opens every read in the integration — evaluations, RUT lookups, the lead list, personal data. That is the whole reason this endpoint exists.

Treat the link as a credential anyway

The report carries the lead's personal data, so anyone holding the link can read it.

The signature does not expire and cannot be revoked. There is no way to withdraw a link once it has been shared. Keep it inside systems you control — your CRM, your back office — and think twice before putting it in a forwardable email or anywhere publicly indexable.

The value changes on every read; the id does not

Each read mints a fresh signature, so two consecutive calls for the same lead return different urlInforme values that open the same report. Older links keep working.

Field	Stable across reads?	Use it to
idPreAprobacion	Yes	compare, deduplicate, key a cache
urlInforme	No — new on every read	open the report

If you diff API responses to detect changes, or cache by URL, key on idPreAprobacion. Otherwise you will see a change that did not happen, and store one cache entry per call.

Where the link comes from

Source	Carries urlInforme?
The pre_approve webhook event	Yes
Get an evaluation by lead id	Yes
Get the latest evaluation by RUT	Yes
List leads — every row	No — idPreAprobacion only
Get lead details	No — by design

The list is a summary and deliberately leaves the link out. For a lead you found there, use its idPreAprobacion with Get the evaluation report, or read the evaluation for that lead and take urlInforme from it.

If you would rather stay server to server

Get the evaluation report is unchanged and still available: it takes your API token and the idPreAprobacion, and returns the pre-signed link as JSON instead of redirecting. Neither endpoint replaces the other.

	This endpoint	Get the evaluation report
Path parameter	signature, received in urlInforme	preApproveId, i.e. idPreAprobacion
API token	Not accepted	Required
Answers	302 to the signed link	200 with { "data": { "url": ... } }
Good for	sharing, embedding, pasting	server-to-server fetches

Both serve the identical document, and both re-render it under the same rule — see Get the evaluation report for when that happens.

Request

Responses

302

Redirect to the pre-signed download link, valid for 1800 seconds. The link forces a download named PreAprobacion_<preApproveId>.pdf.

Response Headers

Location

Pre-signed download link for the PDF. Fetch it with no Authorization header.

404

Not Found - The signature is malformed, or it no longer matches the pre-approval it names. All failures answer the same 404, so a probe cannot tell a bad signature from a report that does not exist.

429

Too Many Requests - Rate limit exceeded

503

Service Unavailable - The report could not be rendered (ERR_UNABLE_TO_RENDER_INFORME) or the download link could not be signed (ERR_AWS_S3_PRESIGNED_GET). Both are 503, not 500.