Resolve a DNI to a person's NAME — informational, never a validation

Answers what RENIEC's registry holds for an eight-digit DNI: the person's names, and nothing else. Informational like the two routes above — no create, no trigger and no dispatch decision resolves a DNI, so a boleta whose acquirer name was typed by hand is issued exactly as before while this route is answering 503. ONLY THE NAME IS RETURNED, AND THAT IS A DECISION RATHER THAN A GAP. The directory this API calls also publishes a person's date of birth and gender, on a different endpoint. That endpoint is never called. Neither datum has a fiscal purpose in this product — a boleta needs at most the acquirer's name — and under Ley 29733's minimisation principle obtaining data with no purpose is the wrong default, not a feature waiting to be finished. Asking for them would be a change to this published contract, not a field somebody appends to a mapper. AND NOTHING IS STORED: not the name, not the DNI, and not a hash of the DNI. An eight-digit space is exhaustible in seconds, so a digest of a DNI identifies the person exactly as well as the DNI does and is not a de-identification of anything. What is recorded is one metered row per consultation carrying the tenant, the verdict CLASS and the instant, because the platform pays a third party for each call and an unattributable spend is one nobody can bill or cap. If you need the name later, keep it yourself, and keep `consultedAt` beside it — this surface has no cache and will not serve you the same answer twice. AN ABSENT ANSWER IS NOT AN ABSENT PERSON, and this is the expensive mistake the route is shaped to prevent. There are two answers and seven non-answers. `found: true` and `found: false` are both 200 and are both statements about the person: `false` means the registry was reached, answered, and holds no such record. Everything else is a 502 or a 503 with its own code and is a statement about the network or about this platform — never about the person. 502 DNI_DIRECTORY_AMBIGUOUS is the one to read twice: it means the directory answered 200 while declaring a failure WITHOUT saying which, so this API refuses to guess that the person does not exist. Treating any of the seven as `found: false` writes our outage into somebody's customer record and refuses a real person a real document. Branch on the STATUS CODE first and on `found` second. Requires consultations:dni, which is NOT consultations:read and is not implied by it. The padrón and exchange-rate routes read free local catalogues about legal entities; this one spends a platform contract, writes a row under row-level security and returns personal data about a natural person. A credential handed to a form so it can prefill a company's legal name must not thereby become a credential that can enumerate people's names.

curl -X GET "https://example.com/api/v2/consultations/dni/string" \  -H "Authorization: Bearer apf_v2_tu_credencial"

{  "schemaVersion": "2.0",  "requestId": "d385ab22-0f51-4b97-9ecd-b8ff3fd4fcb6",  "dni": "string",  "found": true,  "consultedAt": "2019-08-24T14:15:22Z",  "person": {    "fullName": "string",    "firstNames": "string",    "paternalSurname": "string",    "maternalSurname": "string",    "verificationDigit": "string"  }}