Read everything about an application

One application in one read, straight from the Fortress database (no search index, no sync delay), shaped for integration: the application, its household and every live applicant with everything reported for them — one customer object (who the adult is and what they answered on this application), addresses[] and jobs[] tagged by kind, spouse, minor, the income and asset answers as incomes[] and assets[] lines in the vocabulary of GET /incomes and GET /assets, and deductions[]. Every object carries the values the CORA taxonomy compares documents against and the ids a partner joins on, nothing else: no internal columns, audit trails, staff notes, row ids or the portal’s form state; lookup ids come as names/codes, dates as YYYY-MM-DD, amounts as numbers. Each mapping of the document-type definitions (GET /compliance-documents/manifest) names, in applicationSource, the path in this response it compares against.

applicationSource is a reading guide for a person or a model, not a query language: it starts with the path to the entity (applicants[].incomes[], applicants[].customer), may narrow the lines with where <field> = <code> (and adds a condition, or / / list alternatives), and names the fields to read after →, or ends in a field (applicants[].customer.maritalStatus). A ; starts either another path to read as well (it begins with applicants[], as the minors’ names after the adults’) or a note (compare the last 4). Anything in parentheses, and any item after → that is more than a field name (encrypted for the partner), is a note too ((adults), (several entries of one type add up)).

Permissions pick the sections. The route itself needs applications: full-read (granted by name; a * wildcard does not open it). The key’s other grants add sections, and a section the key lacks is absent, not null:

A service wildcard (*: [read]) opens customers, incomes, assets and deductions as it does on the per-resource routes; it never opens the route itself nor sensitive. Income figures stored outside the lines belong to the incomes section too and are absent without it: applicants[].annualIncome, customer.annualIncome and annualSalary on each job.

sensitive: read adds fields to the sections the key already has: the adults’ numbers sit on customer and the minors’ on minor (so they need customers: read too), the account values on the asset lines (so they need assets: read), the claim numbers on the income lines (so they need incomes: read). There is no last-four companion for the Social Security number: a document’s ssn_last4 is compared after decrypting the full value.

With sensitive: read every sensitive value is encrypted for the calling partner exactly as on GET /sensitive/applications/{applicationId} (AES-256-GCM, key = SHA-256 of the partner secret, Base64 of [IV 16 bytes][AuthTag 16 bytes][ciphertext]; see Sensitive values); the ...LastFour companions are plain and always present. The response carries Cache-Control: no-store.

Documents, requirements and review results are not here: read the bundle. An applicant’s id is the applicantId the bundle’s requirements name.

Authenticate with the x-api-key header.