Individual Data

Consent

Consent is identical for individuals and businesses. The individual identifier is an 18-char CURP. For the full payload, response shape, and data dictionary, see the Consents page.

Verification

The Verification object is shared between Individual and Business. See the Verifications page for the lifecycle, the full object reference, and the entities available for Individual identifiers (profile, invoices, employment, employment_files, earnings).

Profile

Personal identity data returned from GET /profile/{identifier}.

personal_info

address

Employment Status

employment_status is a top-level string derived from the individual's employment and invoice records. The API checks signals in priority order and returns the first matching status.

Data must be verified within the last 90 days to be considered. A nomina invoice must also have been issued within the last 60 days. One-off payroll concepts (profit-sharing, year-end bonuses, and severance/settlement payments) do not count as evidence of an active job on their own.

Tenure

tenure is the minimum verified job tenure the individual has with their current employer. The value is returned as a bucket, or null when there is not enough evidence or the profile is not employed.

Tenure is a floor, not an exact duration. For example, 12_months_plus means we can verify at least 12 months; the individual may have worked for the employer longer. The API never overstates tenure.

The extraction window looks back approximately 12 months, so 12_months_plus is the highest possible bucket.

Estimated Monthly Income

estimated_monthly_income is our best estimate of the individual's monthly income in MXN, or null when no income data is available.

It's calculated from the last 90 days of invoices (CFDI) plus employment records, normalized to a monthly figure:

estimated_monthly_income = salary + income invoices − expense invoices

• Only the individual's own invoices count: payroll (nomina) they received, and income (ingreso) / expense (egreso) they issued. Payment receipts (pago) are ignored to avoid double-counting.
• Salary comes from recent payroll when available, otherwise from a current active employment record. This means the estimate now uses employment data, not just invoices, giving much broader coverage than before.
• One-off payroll concepts (profit-sharing, year-end bonuses, and severance/settlement payments) are excluded and not treated as recurring salary.

Invoice

Invoices for an individual are retrieved from GET /invoices/{identifier} using the individual's 18-char CURP.

To improve invoice coverage, clients that already hold the user's RFC can pass it as the optional rfc field when creating a verification (POST /verifications). When provided, the API uses the client-supplied RFC directly to retrieve invoice data, bypassing the internal CURP → RFC conversion.

Incomes and Deductions

For nomina invoices, the response includes incomes and deductions arrays with the line-item breakdown. For other types, both arrays are empty.

Each item has amount, currency, and a free-form detail label (e.g., Sueldo, Aguinaldo, ISR, IMSS). For nomina invoices, items can also include key and type SAT codes that identify and group the income or deduction concept. For the full list of common labels and how to interpret them, see the Invoices page.

Line Items

For ingreso and egreso invoices, the response can include a line_items array with the products or services included in the invoice.

Invoice Relations

For ingreso and egreso invoices, the response can include an invoice_relations array with references to related fiscal documents.

Invoice Types and Payment Info

The SAT defines four invoice types: nomina, ingreso, egreso, pago. Passing include_payment_info=true to GET /invoices/{identifier} enriches each invoice with a payment_info field linking payments to the original invoices they pay.

For the full type reference, payment info structure, and edge cases, see the Invoices page.

Job Risk

The SAT defines occupational risk as follows: