Before you enable it
Three things exist before the Console steps on Credit sources are performed forcirculo_rcc, and none of them is the Platform’s to provide.
Credentials
The credential you supply at the Console is one JSON document. The Platform seals it whole and parses it only at the moment of a consulta; a document without a usable API key cannot authenticate, and the attempt recordscredentials_rejected.
The document you supply as the credential
api_key is complete. Before production, generate the key pair, register its certificate with Círculo, and re-supply the document with both fields, because supplying does not withdraw what is there, so the swap has no window.
Naming a person
A consulta is addressed by identity fields on the application, checked before anything leaves. The required set is the enabled product’s own published contract: the person whole, and the domicile whole.
The Platform transliterates names and address lines on the way out: accents to plain letters, upper case, as the bureau’s contract itself asks; you may state
Ciudad de México and the wire carries CIUDAD DE MEXICO.
An application missing a required field is refused naming it, and nothing reaches Círculo, no consulta is billed and no enquiry registers on the borrower’s file. The refusal is a 422 under source_access, carrying the source’s own sentence:
422, no RFC, captured from a real run
Authorisation
Every consulta runs under the four authorisation fields the application names,consent.artifact_id, given_at, expires_at, attested, checked before anything is fetched, exactly as Credit sources states.
When you set attested, you state on the record that you hold the borrower’s authorisation that the law governing credit information societies requires of the party making the enquiry. The Platform forwards that statement as yours and composes none of its own. The ledger keeps what you attested and when. A consulta made on a false attestation is yours to answer for, to the borrower, to Círculo, and to the authority. Your counsel owns what your authorisation document must say; this is not legal advice.
One authorisation supports one consulta, and a report is never cached and never reused:
- A second decision about the same person is a second consulta under its own
artifact_id. Nothing from the first report is served to it. - A retry of a failed attempt under the same authorisation is the same consulta still being attempted, not a reuse: see the outage section below.
- There is no field in the Platform that could hold a report for reuse: the schema has no column for one.
What comes back
A successful consulta produces four read attributes, each mapped from the report under the published RCC mapping, version 1. A policy version that reads any of them must band theirunavailable state, the coherence rules refuse one that does not.
The decision’s record names the consulta without carrying the report. Captured from a real run, the source list of a recorded decision:
The decision's source list, captured from a real run
source_referenceis the folio Círculo assigned to the consulta, the identifier a dispute is taken back to the bureau under. The same folio stands on the attempt and on the ledger entry.attempt_idis the Platform’s own handle, and the join to your ledger.- The report itself is in none of this. It lives in the satellite beside the decision, under the custody rules, destroyable while the record stands.
No file on the person
A person the bureau holds nothing on is an answer, not an outage. Círculo speaks it two ways: an empty204 response, or its own 404 refusal, No se encontró a la persona, and the Platform records both under the one outcome name subject_not_found. The consulta runs, the attempt records it, and the decision is taken with every RCC attribute in its unavailable state, banded by your policy like any other absence. No retry asks again about a history that does not exist, and because neither spelling carries a folio, the attempt is the only handle that answer has.
When it cannot be reached
The source’s posture isretry: no decision exists, nothing is recorded as one, and the application’s reference stays free. The answer is a 424 naming the attempt, the one thing that provably exists after a response is lost:
424, a consulta that timed out, captured from a real run
details.attempt_id and whether to resubmit from retry: as_is where the source’s failure is retryable, as here, and never where a resubmission would meet the same failure and the outcome has to be settled with the source first.
Resubmit the same application, same reference, same authorisation, once the source recovers. That retry is the same consulta still being attempted, and the recovered run’s decision records the fresh attempt beside the folio it obtained. Both attempts stand in your ledger under the one authorisation.
The failure vocabulary is declared on the source and served back to you on GET /v1/tenants/{tenant_id}/sources, so your handling is written against the declared set rather than reverse-engineered from an outage.
One more outcome can reach your ledger and is not on that table, because it is the Platform’s word rather than Círculo’s:
unreadable_response, always retryable. It means the answer was not the protocol being spoken, a status the contract does not describe, a redirect, or a 200 carrying no folio. The Platform follows no redirect, so nothing carrying your key travels to whatever host one names.
The ledger entry
One consulta, as your ledger answers it, captured from a real run:One ledger entry, captured from a real run
A call that left is one your account may be billed for whatever happened next, so the ledger prices it at the source’s own unit even where the answer never arrived, a connection reset mid-answer or a deadline that passed while waiting is a consulta the bureau may have registered, and whether it did is not knowable from this side. A call that never left cost nothing, keeps its entry and its attempt so you hold the refusal, and does not count against your daily bound. What decides which is which is the transport’s own record of the request having been written, not the name of the failure: a connection the Platform could not open still reads
unreachable, so your retry posture applies, and it still shows as an outage where the Platform watches sources.
The regulatory readings behind this source, who the Usuario is under LRSIC arts. 29 and 30, and what one authorisation may be used for under the Regla Octava, are held conservatively and listed on Lending in Mexico.