> ## Documentation Index
> Fetch the complete documentation index at: https://gotrebol.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# RFC de prueba

> RFC que crean una verificación KYB México con una respuesta fija, para probar tu integración sin gastar créditos.

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. |

> [!NOTE]
>
> 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.

```bash curl theme={"dark"}
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" } }
    ]
  }'
```

```javascript JavaScript theme={"dark"}
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()
```

```python Python theme={"dark"}
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](#los-escenarios).

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 |

> [!TIP]
>
> 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](https://gotrebol.com/docs/guia-devs/webhooks.md).

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**

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 ítems**

Al 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"`).

```json theme={"dark"}
{
  "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.

```json theme={"dark"}
"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.

**B · No encontrado**

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:**

```json theme={"dark"}
{
  "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`:**

```json theme={"dark"}
{
  "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.

**C · Error técnico**

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:**

```json theme={"dark"}
{
  "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`.

**D · Validación de documentos**

Cuatro ítems [`doc_validation`](https://gotrebol.com/docs/guia-devs/crear-verificaciones/via-api/forma-validacion), 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](https://gotrebol.com/docs/guia-devs/crear-verificaciones/via-api/reglas-validacion.md).

**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:

```json theme={"dark"}
{
  "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:

```json theme={"dark"}
{
  "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`:

```json theme={"dark"}
"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
  }
]
```

> [!WARNING]
>
> **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](https://gotrebol.com/docs/guia-devs/crear-verificaciones/via-api/forma-validacion.md#combinar-con-extraccion).

**E · Consulta de RFC**

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:

```json theme={"dark"}
{
  "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)](https://gotrebol.com/docs/guia-devs/uso-kyb/mexico/items-consultas-publicas.md#siger).

```json theme={"dark"}
{
  "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`](https://gotrebol.com/docs/guia-devs/uso-kyb/mexico/items-consultas-publicas) 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.

```json theme={"dark"}
{
  "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`.

> [!WARNING]
>
> **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`](https://gotrebol.com/docs/api-reference/agregar-items-a-una-verificacion/agregar-items-a-una-verificación-existente). 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](https://gotrebol.com/docs/guia-devs/referencia/errores-consultas-publicas.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.