RFC de prueba

Los RFC de prueba te permiten provocar por API los casos que en producción no puedes elegir: que todo salga bien, que las fuentes públicas no encuentren a la empresa, que fallen por un problema técnico o que un documento no pase sus reglas de validación. Cada RFC crea una verificación KYB México que siempre responde lo mismo. Los escenarios A, B y C son verificaciones completas, con documentos y consultas públicas. D y E reproducen un solo flujo.

RFC	Escenario	Qué te permite probar
`TRB010101OK1`	A · Todo encontrado	El camino feliz y cómo se ve la información reconciliada.
`TRB010101NF1`	B · No encontrado	Un resultado definitivo: las fuentes respondieron y no encontraron el dato.
`TRB010101ER1`	C · Error técnico	Documentos que no se pudieron leer y consultas que fallaron.
`TRB010101DV1`	D · Validación de documentos	Ítems `doc_validation` con reglas de validación que pasan, reglas que no pasan y un documento de otro tipo.
`TRB010101RF1`	E · Consulta de RFC	Solo las consultas públicas: los certificados del SAT de la empresa y de su representante legal, y su registro en SIGER.

Una verificación de prueba no consulta ninguna fuente externa (SAT, SIGER, INE ni RENAPO) y no se cobra. Trébol la marca con la etiqueta prueba-trebol.

Crear una verificación de prueba

Usa POST /verifications con la API key de tu cuenta de prueba, igual que para una verificación real. Manda el cuerpo completo: country, tag, tax_id con uno de los RFC y al menos un ítem válido.

curl -X POST https://api.gotrebol.com/verifications \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "country": "mx",
    "tag": "prueba-escenario-a",
    "tax_id": "TRB010101OK1",
    "items": [
      { "type": "ac_mx", "options": { "file_url": "https://example.com/acta.pdf" } }
    ]
  }'

const response = await fetch("https://api.gotrebol.com/verifications", {
  method: "POST",
  headers: {
    "x-api-key": "YOUR_API_KEY",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    country: "mx",
    tag: "prueba-escenario-a",
    tax_id: "TRB010101OK1",
    items: [
      { type: "ac_mx", options: { file_url: "https://example.com/acta.pdf" } },
    ],
  }),
})
const verification = await response.json()

import requests

response = requests.post(
    "https://api.gotrebol.com/verifications",
    headers={"x-api-key": "YOUR_API_KEY"},
    json={
        "country": "mx",
        "tag": "prueba-escenario-a",
        "tax_id": "TRB010101OK1", 
        "items": [
            {"type": "ac_mx", "options": {"file_url": "https://example.com/acta.pdf"}}
        ],
    },
)
verification = response.json()

Trébol valida la petición como cualquier otra, así que un cuerpo mal formado recibe el mismo error que en producción. Después reemplaza tus ítems por los del escenario:

La respuesta 201 trae 22 ítems en el escenario A, 17 en B y C, 4 en D y 4 en E, todos en pending.
country queda en mx aunque mandes otro valor.
Los archivos que mandes se ignoran sin fallar. No subas nada a las upload_url que aparecen en los ítems: cada ítem documental se resuelve con un PDF de ejemplo.
El mismo RFC devuelve la misma respuesta cada vez. Solo cambian los identificadores (id de la verificación y de los ítems) y las URL firmadas.

Cómo avanza la verificación

La verificación de prueba no nace terminada: sus ítems se completan en el tiempo, igual que en producción. Así puedes probar cómo responde tu integración mientras la verificación todavía está en curso. En los escenarios A, B y C:

Segundos desde la creación	Ítems que se completan
10 – 30	`csf_mx`, `proof_address` y `bank_statement`
35 – 55	`person_id`, `fme_mx` y `pw_mx`
60 – 90	las dos `aa_mx` y el `ac_mx`
~100	`siger`
110 – 120	los dos `public_sat_signatures`

Los tiempos reales llevan entre 5 y 15 segundos de desfase por el encolado. La verificación pasa a finished unos 2 minutos y medio después de crearla, cuando se completa el último ítem. D y E son más cortos. D termina en 1 minuto, cuando ya se completaron sus cuatro ítems. E termina en menos de 1 minuto, pero dos de sus ítems se completan después de que la verificación pasa a finished. Cada uno detalla sus tiempos en su pestaña. Lo que ves en A, B y C según el momento en que consultes:

Momento	`GET /verifications/{id}`	`shareholders`	`people`	`external_identities`
Recién creada	`status: "pending"`, todos los ítems en `pending`	vacía, con `shareholders_unavailable_reason: "pending_extraction"`	vacío	ausente
A la mitad	`status: "pending"`, unos ítems en `complete`	se llena cuando termina la primera acta con accionistas	los roles de los documentos ya procesados	aparece unos 20 segundos después del documento que aporta la CURP
Al terminar	`status: "finished"`, todos los ítems en `complete`	el resultado final del escenario	completo	presente solo en el escenario A

Los webhooks funcionan igual que en una verificación real. Si los tienes configurados en tu cuenta de prueba, Trébol te notifica cada cambio de la verificación de prueba sin que configures nada extra. Consulta Webhooks.

Consulta los resultados con los mismos endpoints de siempre:

GET /verifications/{verification-id} — la verificación con todos sus ítems.
GET /verification-items/{id} — un ítem.
GET /v2/verifications/{verification-id}/{entity} — las secciones reconciliadas details, people y shareholders.

Los escenarios

El escenario A es la referencia. B y C se describen por lo que cambia respecto de A. D y E no se comparan con A: cada uno reproduce un flujo distinto.

A · Todo encontrado
B · No encontrado
C · Error técnico
D · Validación de documentos
E · Consulta de RFC

Una S.A. de C.V. con dos accionistas y seis personas con roles. Los 22 ítems se procesan y las cuatro consultas públicas responden con éxito.Los 22 ítemsAl terminar, los 22 ítems están en item_status: "complete", sin item_error, y cada uno trae su item_value poblado:

`item_type`	Sujeto	Qué trae `item_value`
`ac_mx`	la empresa (acta constitutiva)	Número y fecha del acta, notario, tipo de sociedad, capital, los accionistas en `shareholders` y los firmantes con sus roles y poderes en `signatories`.
`aa_mx`	la empresa (asamblea de accionistas)	La nueva composición accionaria en `shareholders`.
`aa_mx`	la empresa (asamblea de administración)	El consejo de administración en `signatories`.
`pw_mx`	la empresa (poder notarial)	El apoderado y sus poderes en `signatories`.
`fme_mx`	la empresa (folio mercantil)	El folio mercantil `N-2019012345` y su fecha de inscripción.
`csf_mx`	la empresa	RFC `TRB010101OK1`, razón social, régimen, actividades, domicilio fiscal y validación QR.
`csf_mx`	la presidenta	RFC, CURP y nombre de la presidenta.
`person_id`	la presidenta (`ine_mx`)	Datos de la credencial e `ine_validation_result: "valid_id"`.
`person_id`	el administrador único (`passport`)	Datos del pasaporte. `ine_validation_result` llega en `null`: la validación del INE solo corre con `ine_mx`.
`person_id`	la comisaria (`residence_mx`)	Datos de la residencia, con `ine_validation_result` en `null`.
`proof_address` ×2	la empresa (CFE) y la presidenta (TELMEX)	Proveedor, dirección y la dirección desglosada en `mx_address`.
`bank_statement` ×2	la empresa (BBVA) y la presidenta (Santander)	`banking_information` con banco, CLABE, cuenta y moneda.
`siger`	la empresa	`legal_name` y `documents`, con el folio y los actos inscritos.
`public_sat_signatures` ×2	la empresa y sus representantes	`data.{rfc}.status: "success"` con dos certificados.
`person_id`	el accionista persona física (`ine_mx`)	Datos de la credencial e `ine_validation_result: "valid_id"`.
`csf_mx`	el accionista persona física	RFC, CURP y nombre del accionista.
`proof_address`	el accionista persona física	Su comprobante de domicilio.
`csf_mx`	el accionista persona moral	RFC `IDE150320AB3` y razón social del accionista.
`proof_address`	el accionista persona moral	Su comprobante de domicilio.

Los últimos cinco ítems existen solo en este escenario, para que los accionistas también tengan información reconciliada.shareholders. Dos accionistas, una persona moral y una física. La información sale de la asamblea de accionistas (source.item_type: "aa_mx").

{
  "shareholders": [
    {
      "name": "INVERSIONES DEMO, S.A. DE C.V.",
      "type": "business",
      "id_type": "rfc",
      "id_number": "IDE150320AB3",
      "fixed_shares": "600.00",
      "fixed_value": "60000.00",
      "total_shares": "900.00",
      "total_value": "90000.00",
      "share_percentage": 60,
      "identity": { "address_data": { "...": "..." } },
      "fiscal": { "csf_mx": { "status": "ACTIVO", "rfc": "IDE150320AB3" } },
      "address": { "proof_address": { "...": "..." } }
    },
    {
      "name": "MARTÍNEZ SOTO JORGE",
      "type": "person",
      "id_type": "curp",
      "id_number": "MASJ750620HDFRTR03",
      "fixed_shares": "400.00",
      "fixed_value": "40000.00",
      "share_percentage": 40,
      "identity": { "person_id": { "...": "..." }, "address_data": { "...": "..." }, "basic_data": { "...": "..." } },
      "fiscal": { "csf_mx": { "status": "ACTIVO", "rfc": "MASJ750620QW1", "curp": "MASJ750620HDFRTR03" } },
      "address": { "proof_address": { "...": "..." } },
      "external_identities": { "curp": { "search_number": "MASJ750620HDFRTR03", "success": true } }
    }
  ],
  "capital": { "fixed_value": "100000.00", "total_value": "150000.00", "...": "..." },
  "shareholders_unavailable_reason": null,
  "business_type": "SOCIEDAD ANONIMA DE CAPITAL VARIABLE"
}

Las acciones y los montos llegan como strings. La constancia fiscal de la persona moral se reconcilia por su RFC: aparece en su fiscal y no en details.tax. La persona moral no trae external_identities: RENAPO solo corre cuando hay CURP.people. key_people trae cinco personas y full_list siete.

Persona	`role_name`	`group_name`	`event`	Poderes
GARCÍA LÓPEZ ANA SOFÍA	`presidente`	`board_members`	`addition`	los seis, `individual`, sin límites
TORRES MEDINA RICARDO	`administrador unico`	`executives`	`removal`	los seis, `individual`, sin límites
VEGA CASTRO LUIS ALBERTO	`secretario`	`board_members`	`addition`	tres, `joint`
PÉREZ LARA MARIANA	`vocal`	`board_members`	`addition`	tres, `joint`
HERRERA GÓMEZ DIEGO	`apoderado`	`proxies`	`addition`	mixto: uno `individual`, uno `joint` y uno con `has_power: false`

La comisaria (NUÑEZ SALAS PATRICIA) no tiene poderes, así que aparece en full_list pero no en key_people. Un poder con has_power: false significa que se consideró y no se otorgó, que es distinto de no aparecer en la lista.RENAPO. Seis personas traen external_identities.curp con success: true. El administrador único no lo trae porque su identificación es un pasaporte, sin CURP.

"external_identities": {
  "curp": {
    "search_number": "GALA900112MDFRPN04",
    "success": true,
    "applicant_data": {
      "curp": "GALA900112MDFRPN04",
      "names": "ANA SOFÍA",
      "first_surname": "GARCÍA",
      "second_surname": "LÓPEZ",
      "evidentiary_document": "Acta de nacimiento"
    }
  }
}

details. Llegan pobladas las secciones legal, registration, tax, banking y address. tax.business_tax_id es TRB010101OK1: el RFC de la empresa verificada, no el del accionista persona moral.

Las fuentes responden y ninguna encuentra. Los documentos se leen bien. El resultado es definitivo: si creas el ítem de nuevo, vas a recibir lo mismo. Lo que procede es corregir el dato o pedir otro documento.Qué cambia respecto de A

Dónde	Qué recibes
Composición	17 ítems: no están los cinco documentos de los accionistas.
`siger`	`item_status: "complete"` con `item_value: {}`: SIGER no encontró a la empresa.
`public_sat_signatures` ×2	`item_status: "complete"`. En `item_value.data.{rfc}`: `status: "fail"`, `validation_result.reason: "rfc_not_found"` y `certificates: []`.
`person_id` con `ine_mx`	`ine_validation_result: "invalid_id"`: la identificación se verificó y resultó inválida. Es un resultado, no un error de sistema. El pasaporte y la residencia siguen con `ine_validation_result: null`, como en A: la validación del INE solo corre con `ine_mx`.
RENAPO	Ninguna persona trae `external_identities`.
`shareholders`	Lista vacía con `shareholders_unavailable_reason: "business_type_without_shareholders"`.
`people`	`key_people: []`: nadie tiene poderes. Las seis personas siguen en `full_list`.
`details`	La empresa es una sociedad cooperativa: `business_type: "SOCIEDAD COOPERATIVA LIMITADA"`.

El ítem del SAT:

{
  "item_status": "complete",
  "item_type": "public_sat_signatures",
  "item_value": {
    "tax_ids": ["TRB010101NF1"],
    "data": {
      "TRB010101NF1": {
        "status": "fail",
        "tax_id_number": "TRB010101NF1",
        "legal_name": "",
        "certificates": [],
        "validation_result": { "success": false, "reason": "rfc_not_found" }
      }
    }
  }
}

shareholders:

{
  "shareholders": [],
  "source": null,
  "capital": null,
  "shareholders_unavailable_reason": "business_type_without_shareholders",
  "business_type": "SOCIEDAD COOPERATIVA LIMITADA"
}

Una sociedad cooperativa no tiene accionistas por su naturaleza jurídica. La lista vacía es la respuesta correcta y final, no una falla.

Dos documentos no se pudieron leer y las consultas públicas fallaron por un problema técnico. Aquí sí vale la pena crear el ítem de nuevo, porque la segunda vez puede salir bien.Qué cambia respecto de A

Dónde	Qué recibes
Composición	17 ítems, los mismos que en B.
`ac_mx` y `csf_mx` de la empresa	`item_status: "complete"` con `item_error: "get_input_file_info_failed"` e `item_value: {}`. No traen documento.
`siger`	`item_status: "complete"` con `item_value: {}`: la consulta no pudo completarse.
`public_sat_signatures` ×2	`item_status: "complete"`. En `item_value.data.{rfc}`: `status: "fail"`, `validation_result.reason: "scraper_error"` y `certificates: []`.
`person_id` con `ine_mx`	`ine_validation_result: "maximum_retries_reached"`. El pasaporte y la residencia siguen con `null`, como en A.
RENAPO	Ninguna persona trae `external_identities`.
`documents_status`	`partial_upload`, porque dos documentos no tienen archivo.

Un documento que no se pudo leer:

{
  "item_status": "complete",
  "item_type": "ac_mx",
  "item_error": "get_input_file_info_failed",
  "item_value": {}
}

item_status sigue en complete. Ese campo solo toma pending o complete: el fallo se lee en item_error.Consecuencias en las secciones reconciliadas. Un dato existe solo si el documento que lo respalda se procesó:

people: key_people trae cuatro personas (presidente, secretario, vocal y apoderado), porque su asamblea y su poder sí se leyeron. El administrador único deja de aparecer en key_people: su rol venía del acta constitutiva que falló.
shareholders: los dos accionistas siguen presentes, porque vienen de la asamblea de accionistas (source.item_type: "aa_mx") y no del acta constitutiva.
details: registration y tax llegan vacíos, porque dependen del acta constitutiva y de la constancia fiscal de la empresa. legal, banking y address.business_comercial_address siguen poblados.

La verificación sí llega a finished: que un ítem falle no la deja en pending.

Cuatro ítems doc_validation, cada uno con el tipo de documento esperado y una regla de validación. Uno pasa, dos no cumplen su regla y otro resulta ser un documento de otro tipo. Reproduce lo que recibes cuando validas documentos con reglas de validación.Los 4 ítems

Segundos	Documento esperado	Regla	Tipo correcto	Regla cumplida	`item_internal_status`
~15	`csf_mx`	`vr_trebol_antiguedad` (60 días)	sí	no: emitida el 2026-01-10	`validation_failed`
~30	`ac_mx`	`accionistas_rule` (personalizada)	sí	sí	`validation_success`
~45	`person_id`	`vr_trebol_vencimiento`	sí	no: vigente hasta 2025	`validation_failed`
~60	`bank_statement`	`vr_trebol_antiguedad` (60 días)	no: es un recibo de CFE	sí	`validation_failed`

La verificación pasa a finished alrededor de 1 minuto después de crearla. Los cuatro ítems quedan en item_status: "complete", también los que no pasaron.Los resultados son fijos porque son verificaciones de ejemplo: las reglas se evaluaron el 2026-10-01 y no se recalculan con la fecha del día. Por eso el recibo emitido el 2026-08-05 cumple la regla de 60 días (tenía 57) y la constancia del 2026-01-10 no.Un documento que no cumple su regla. El tipo es correcto, pero la constancia tiene más de 60 días:

{
  "item_status": "complete",
  "item_type": "doc_validation",
  "item_internal_status": "validation_failed",
  "item_value": {
    "item_type_validation_result": [
      {
        "validation_result": true,
        "reason": "The document is a \"Constancia de Situación Fiscal\" issued by the \"SERVICIO DE ADMINISTRACIÓN TRIBUTARIA\" for a persona moral, ..."
      }
    ],
    "rules_validation_result": [
      {
        "id": "vr_trebol_antiguedad",
        "variable_value": "2026-01-10",
        "validation_result": false
      }
    ]
  }
}

Un documento de otro tipo. Se esperaba un estado de cuenta y llegó un recibo de luz. La regla de antigüedad sí se cumple, pero el ítem no pasa porque el tipo no coincide:

{
  "item_status": "complete",
  "item_type": "doc_validation",
  "item_internal_status": "validation_failed",
  "item_value": {
    "item_type_validation_result": [
      {
        "validation_result": false,
        "reason": "The document is a CFE electricity bill (\"Comisión Federal de Electricidad\") ... It is a proof of address, not a bank statement: it has no bank name, CLABE, account number or transaction detail."
      }
    ],
    "rules_validation_result": [
      {
        "id": "vr_trebol_antiguedad",
        "variable_value": "2026-08-05",
        "validation_result": true
      }
    ]
  }
}

Una regla personalizada. Solo las reglas personalizadas devuelven su texto en validation_rule. Las predefinidas (vr_trebol_*) solo traen su id:

"rules_validation_result": [
  {
    "id": "accionistas_rule",
    "validation_rule": "Que tenga seccion con accionistas nombres y montos.",
    "variable_value": "INVERSIONES DEMO, S.A. DE C.V. ($90,000.00); MARTÍNEZ SOTO JORGE ($60,000.00)",
    "validation_result": true
  }
]

El motivo del rechazo no viene en item_error. Un ítem que no pasa trae item_internal_status: "validation_failed" y ningún item_error. Para saber por qué falló, revisa el item_value:

item_type_validation_result[0].validation_result: false: el documento no es del tipo esperado.
Si el tipo es correcto, la regla con validation_result: false en rules_validation_result es la que no se cumplió.

Secciones reconciliadas. details, people y shareholders llegan vacías, porque validar un documento no extrae su información. Para extraerla, agrega un ítem con el tipo directo, como se explica en Combinar con extracción.

Una consulta de RFC sin documentos: los certificados del SAT de la empresa, los de su representante legal, su registro en SIGER y las empresas relacionadas con sus socios. Las cuatro consultas responden con éxito. La empresa es una S. de R.L. de C.V. con seis actos inscritos en su folio mercantil.Los 4 ítems

Segundos	`item_type`	`item_internal_status`	Qué trae `item_value`
~10	`public_sat_signatures` (`business`)	`screenshot_taken`	Los certificados de la empresa `TRB010101RF1`: un sello y una FIEL activos y su historial de certificados caducos o revocados.
~45	`public_sat_signatures` (`representatives`)	`screenshot_taken`	Los certificados del representante legal, con su propio RFC: una FIEL activa y su historial.
~120	`siger`	`siger_documents_found`	El folio mercantil `N-2024095979` con sus seis actos, el objeto social, la duración y los dos socios.
~200	`siger_shareholders`	`siger_shareholders_scrap_completed`	Las empresas en las que participa cada uno de los dos socios.

La verificación pasa a finished alrededor de 45 segundos después de crearla, en cuanto terminan las dos consultas del SAT. siger y siger_shareholders siguen completándose después, igual que en producción: la verificación no espera a siger porque se creó sin siger_data_extraction, y siger_shareholders es un ítem opcional. Si tu integración lee SIGER, no lo des por ausente solo porque la verificación ya está en finished; espera a que esos ítems pasen a complete.De la empresa a su representante. Los certificados activos de la empresa nombran a su representante legal en legalRepresentativeRFC. Ese RFC es el que consulta el ítem representatives, así que su tax_ids no es el de la empresa:

{
  "item_type": "public_sat_signatures",
  "item_internal_status": "screenshot_taken",
  "item_value": {
    "tax_ids": ["RUTD800515AB2"],
    "data": {
      "RUTD800515AB2": {
        "status": "success",
        "tax_id_number": "RUTD800515AB2",
        "legal_name": "DIEGO ALBERTO RUIZ TORRES",
        "business_type": "",
        "certificates": [
          {
            "numeroSerie": "00001000000700912351",
            "estado": "Activo",
            "tipo": "FIEL",
            "fechaInicial": "2026-04-06T19:05:09.000Z",
            "fechaFinal": "2030-04-06T19:05:49.000Z",
            "personEmail": "firmante@demo.mx",
            "...": "..."
          },
          { "estado": "Revocado", "tipo": "FIEL", "...": "..." }
        ],
        "...": "..."
      }
    }
  }
}

Los actos de SIGER. Cada acto trae su fme_assembly_minute_extractor, con los eventos que Trébol detectó en él: la constitución, dos cambios de domicilio, cambios en el consejo de gerentes y revocaciones de poderes. Es la misma estructura que describe Análisis automático de minutas (FME).

{
  "act": "Nombramiento de apoderados y sus respectivas facultades",
  "pre_coded_form": "M2 - Asamblea",
  "nci": "202400360666",
  "mode": "Incidencia",
  "registration_date": "2024-12-02T12:00:00+00:00",
  "fme_assembly_minute_extractor": [
    {
      "event_group_name": "administration_events",
      "events": ["adicion_administracion", "remocion_administracion"],
      "explanation": "Se revoca el nombramiento de Carlos Vega Luna como miembro del consejo de gerentes y se nombra a Jorge Salinas Peña y Elena Fuentes Mora como nuevos miembros del consejo de gerentes."
    },
    { "event_group_name": "signatories_holders_events", "events": ["remocion_apoderados"], "...": "..." }
  ]
}

Empresas relacionadas. Después de SIGER, el ítem siger_shareholders busca a cada socio en SIGER y lista las empresas en las que aparece. Los socios llegan como SIGER los devuelve: con el nombre completo en paternal_surname y type: "individual", aunque sean sociedades.

{
  "item_type": "siger_shareholders",
  "item_internal_status": "siger_shareholders_scrap_completed",
  "item_value": {
    "shareholders": [
      { "name": "", "paternal_surname": "DESARROLLOS DEMO, LLC", "maternal_surname": "", "type": "individual" },
      { "name": "", "paternal_surname": "INVERSIONES COSTA DEMO, LTD.", "maternal_surname": "", "type": "individual" }
    ],
    "data": [
      {
        "shareholder": { "name": "", "paternal_surname": "DESARROLLOS DEMO, LLC", "maternal_surname": "", "type": "individual" },
        "related_companies": [
          { "name": "DESARROLLOS INMOBILIARIOS DEMO, S.A. DE C.V.", "fme": "N-2015041122", "type": "company" },
          { "name": "MARINA DEMO LOS CABOS, S. DE R.L. DE C.V.", "fme": "N-2018063307", "type": "company" },
          { "name": "CLUB TRÉBOL DEMO, S. DE R.L. DE C.V.", "fme": "N-2024095979", "type": "company" }
        ]
      },
      { "shareholder": { "paternal_surname": "INVERSIONES COSTA DEMO, LTD.", "...": "..." }, "related_companies": ["..."] }
    ],
    "scraped_at": "2026-09-28T16:42:05.000Z"
  }
}

La empresa verificada aparece entre las relacionadas de cada socio, porque los dos participan en ella.Secciones reconciliadas. Como no hay documentos, casi todo llega vacío:

details: solo legal.business_folio_number trae valor (N-2024095979), y solo cuando siger ya se completó. tax.has_constancia es false.
people y shareholders: vacías, con shareholders_unavailable_reason: null. Los dos socios solo aparecen dentro del item_value de siger y siger_shareholders.

Distinguir «no encontrado» de «error técnico»

Comparar B contra C te enseña a decidir qué hacer con cada resultado.

Fuente	B · No encontrado	C · Error técnico
SAT	`item_value.data.{rfc}.validation_result.reason: "rfc_not_found"`	`item_value.data.{rfc}.validation_result.reason: "scraper_error"`
INE	`item_value.ine_validation_result: "invalid_id"`	`item_value.ine_validation_result: "maximum_retries_reached"`
Documentos	se leen bien: `item_value` poblado y sin `item_error`	`item_error: "get_input_file_info_failed"` e `item_value: {}`
SIGER	`item_value: {}` e `item_internal_status: "siger_not_found"`	`item_value: {}` e `item_internal_status: "siger_not_found_ops_forced"`

En SIGER, item_value llega vacío en los dos casos: la única diferencia está en item_internal_status.

La API responde 200 aunque la consulta externa falle, y item_status es complete en los dos casos. Si tu integración solo revisa el código HTTP, item_status o status: "fail", no puede distinguir B de C.

Qué hacer con cada uno:

No encontrado (B): el resultado no va a cambiar. Pide al usuario que corrija el RFC o que cargue otro documento.
Error técnico (C): crea el ítem de nuevo con PUT /verifications/{verification-id}/add-items. Como el fallo fue técnico, el nuevo ítem puede completarse bien.

En los dos casos, no puedes reintentar la lectura del mismo ítem. Trébol ya agotó sus reintentos internos antes de emitir el estado, así que lo que recibes es final. Para el catálogo completo de indicadores por fuente, consulta Errores en consultas públicas.

Intro al API de Trébol

Guías por caso de uso

Crear una verificación de prueba

Cómo avanza la verificación

Los escenarios

Distinguir «no encontrado» de «error técnico»

​Crear una verificación de prueba

​Cómo avanza la verificación

​Los escenarios

​Distinguir «no encontrado» de «error técnico»

Crear una verificación de prueba

Cómo avanza la verificación

Los escenarios

Distinguir «no encontrado» de «error técnico»