Modo de prueba: RUT, valores y simulación

El modo de prueba te deja ejercitar la integración completa contra https://api.redcumbre.cl sin que nada llegue al SII, sin cobros y sin mensajes a personas reales. Esta página reúne lo que necesitas para usarlo y remite a la guía de cada servicio para el detalle. Cómo funciona el modo —por qué es una propiedad de la credencial y no un servidor aparte, y qué ocurre y qué no— está en Entornos y modo de prueba.

Crear una llave de prueba

Con el CLI, en la carpeta de tu proyecto:

npx @redcumbrecl/cli init

Inicia sesión en el navegador y deja una llave de prueba sin preguntar, en keys/redcumbre-prueba.json, con el .env apuntando a ese archivo. --entorno prueba|real elige cuál instalas; la llave real la agregas cuando estés listo, con npx @redcumbrecl/cli init --entorno real.

Sin Node, en el panel:

Entra al panel de tu empresa y ve a Configuración > API Keys.
Presiona Crear API Key, elige el rol y marca Llave de prueba.
Guarda el secreto: se muestra una sola vez.

El modo de una llave no se puede cambiar después: para operar de verdad creas una llave real. Confirma de qué modo es una llave con GET /{tenantSlug}/whoami: la respuesta trae credencial.sandbox.

Probar con el CLI

Con la llave de prueba instalada, el CLI trae lo que necesitas para ejercitar la integración desde la terminal:

Comando	Qué hace
`redcumbre escenarios`	Los emisores, los RUT y las simulaciones del modo de prueba de tu empresa
`redcumbre eventos` · `redcumbre eventos disparar <evento>`	Los eventos de webhook del modo de prueba, y dispara uno a tu endpoint de prueba
`redcumbre webhooks escuchar --reenviar-a <url>`	Recibe en tu computador los webhooks de la empresa y los reenvía a tu aplicación local
`redcumbre bandeja`	Los correos y mensajes que el modo de prueba retuvo en vez de enviarlos
`redcumbre restaurar --confirmar <slug>`	Borra lo que creaste en prueba y vuelve a cargar los datos de ejemplo
`redcumbre api <operación>`	Ejecuta una operación de la API con la llave del proyecto
`redcumbre receta <nombre>`	Agrega a tu proyecto un ejemplo que funciona en el modo de prueba

Las llaves de prueba anteriores se retiraron

El modo de prueba actual reemplaza al anterior y no arrastra nada de él. Las API Keys de prueba que existían antes se retiraron sin aviso previo. Si tu key de prueba de antes ahora responde 401 con INVALID_JWT_TOKEN, es eso: la credencial ya no existe y no se puede reactivar. Crea una nueva como se explica arriba; tu código no necesita otro cambio, porque la URL y los endpoints son los mismos.

La baja deja de autenticar en hasta 5 minutos: mientras tanto, una llamada con la key retirada puede seguir respondiendo como antes.
Los datos de prueba que esas keys crearon también se retiraron. Se conservó como real lo que llegó al SII de producción o se cobró, lo que un documento real usa y lo que es parte de una certificación ante el SII.
Tus llaves reales no se tocaron, aunque su nombre diga «prueba» o «test»: el retiro alcanzó sólo a las llaves creadas como llaves de prueba.
Las API Keys de prueba que creaste en el modo de prueba actual no se tocaron: siguen funcionando.

RUT de prueba

En el modo de prueba la plataforma reconoce sólo estos diez RUT. Su identidad es sintética: no corresponde a ninguna persona ni empresa real. No cambian una vez publicados, así que puedes escribirlos en tus pruebas automatizadas.

RUT	Para qué sirve	Se presenta como
`77777777-7`	Emisor de documentos tributarios (persona jurídica)	EMPRESA DE PRUEBA RCAPI SPA
`11111111-1`	Emisor de boletas de honorarios propias (persona natural)	PROFESIONAL DE PRUEBA RCAPI
`88888888-8`	Emisor de boletas de terceros; además cliente y proveedor persona jurídica	SERVICIOS DE PRUEBA RCAPI LIMITADA
`66666666-6`	Cliente genérico «público general», como en el SII real	PUBLICO GENERAL
`55555555-5`	Cliente genérico extranjero sin domicilio en Chile, como en el SII real	EXTRANJEROS SIN RUT
`22222222-2`	Cliente y proveedor persona natural	CONTRIBUYENTE DE PRUEBA DOS
`33333333-3`	Cliente y proveedor persona natural	CONTRIBUYENTE DE PRUEBA TRES
`12345678-5`	Cliente y proveedor persona natural; contribuyente de la tokenización de prueba	CONTRIBUYENTE DE PRUEBA TOKENIZADO
`44444444-4`	Receptor que el SII simulado siempre rechaza	RECEPTOR RECHAZADO DE PRUEBA
`99999999-9`	Responde «no encontrado»	CONTRIBUYENTE INEXISTENTE DE PRUEBA

Un RUT válido que no está en la tabla responde lo mismo que un RUT que el SII no conoce: el mismo 404 que vas a recibir en producción. El modo de prueba nunca devuelve datos de un contribuyente real.

Los emisores de prueba, sus clientes, proveedores y productos de ejemplo vienen precargados en tu empresa: no tienes que crearlos.

Qué simula cada servicio

Servicio	Valores y acciones de prueba	Detalle
Documentos tributarios (DTE)	Emites con el emisor `77777777-7` los tipos 33, 34, 39, 41, 43, 46, 52, 56 y 61. El receptor `44444444-4` provoca el rechazo del SII simulado. Sobre un documento de prueba hay cuatro acciones de simulación: `POST /{tenantSlug}/dte/{id}/simulacion/reparos`, `…/anular`, `…/reclamo-receptor` y `…/aceptacion-receptor`. El PDF de respaldo del SII no existe en prueba, y tampoco el XML: el enlace `xmlUrl` del documento viene `null`.	DTE
Boletas de honorarios (BHE)	Emisor `11111111-1`, sin clave del SII y sin el servicio contratado.	Boletas de Honorarios
Boletas de terceros (BHET)	Emisor `88888888-8`, sin clave del SII y sin el servicio contratado.	Boletas de Terceros
Anulación de boletas	Anular, reintentar y llevar una anulación a «no anulable» con `POST /{tenantSlug}/bhe/anulaciones/{anulacionId}/simular-no-anulable` (y su par en `bhet`).	Anulación
Emisión masiva	El lote corre de verdad. No tiene tope propio: cada documento del lote cuenta uno en el tope de documentos tributarios, igual que uno emitido de a uno.	Procesos batch
Consulta y validación de RUT	Responden por el catálogo de arriba: identidad sintética para los diez RUT, `404` para cualquier otro y para `99999999-9`. Sin consulta al SII y sin cobro.	Consulta de RUT
Tokenización de emisores	Contribuyente `12345678-5` con la clave tributaria `clave-de-prueba`.	Emisores
SMS	No se llama al proveedor ni se cobra: el mensaje queda en la bandeja de mensajes simulados y su estado avanza solo. El teléfono `+56222222244` fuerza la entrega fallida.	SMS y WhatsApp de prueba
WhatsApp	No se llama a Meta ni se cobra: despachas por el canal de prueba con una de sus plantillas de ejemplo, el mensaje queda en la bandeja de mensajes simulados y la respuesta trae `sandbox: true`.	SMS y WhatsApp de prueba
Autorizaciones	Las solicitudes funcionan igual que en real y sus respuestas traen `sandbox: true`. El flujo está habilitado en prueba para toda empresa, con la configuración de prueba.	La configuración de autorizaciones de prueba
Webhooks	Los eventos de prueba van a la URL que declaró la operación o, si no declaró ninguna, a la URL por defecto de prueba de tu empresa, con `sandbox: true` en el payload y firmados con el secreto de prueba.	Webhooks

La bandeja de mensajes simulados

Todo correo, SMS o WhatsApp que una operación de prueba habría enviado queda en la bandeja de tu empresa, con su destinatario, su canal y su contenido. La lees con GET /{tenantSlug}/modo-prueba/bandeja.

Los webhooks de prueba

El modo de prueba tiene su propia configuración de webhooks, distinta de la real: su propio secreto de firma, sus headers y su URL por defecto. La configuras en General → Webhooks con el panel en Prueba. Los avisos de prueba siguen la misma regla de destino que los reales (A dónde va cada aviso): si la operación no declaró su URL y no hay URL por defecto de prueba, el aviso no se envía —nunca se desvía a tu URL real— y queda como «no enviada». Un evento real nunca llega a la URL de prueba.

Cada entrega queda en el historial de entregas, en la pestaña «Historial de entregas» de General → Webhooks: con el panel en Prueba ves sólo las entregas de prueba, y en Real sólo las reales. Es una pantalla para personas: tu API Key no la consulta. Tu integración sabe lo que recibió por su propio endpoint.

El tope diario

Cada servicio admite hasta 200 operaciones de prueba al día por empresa, contadas por separado: documentos tributarios, boletas de honorarios, boletas de terceros, validación de RUT, tokenización, SMS, WhatsApp, autorizaciones, clientes y proveedores. Cada documento de un lote de emisión masiva cuenta uno en el tope de documentos tributarios. Al superarlo, la operación responde 400 con MODO_PRUEBA_TOPE_DIARIO, cuánto te queda y que el tope se renueva a las 00:00 de Chile. Lo consultas sin consumirlo con GET /{tenantSlug}/modo-prueba/tope-diario/{servicio}.

SMS y WhatsApp de prueba

Un SMS o un WhatsApp de prueba no sale a nadie, pero su estado avanza solo, como el de un mensaje real. El del SMS lo consultas con GET /{tenantSlug}/sms/messages/{messageId}; el del WhatsApp, además, llega como evento whatsapp.mensaje.estado a tu endpoint de webhook de prueba:

Canal	Recorrido normal	Al teléfono `+56222222244`
SMS	`queued` → `sent` → `delivered`	`queued` → `sent` → `undelivered`
WhatsApp	`submitted` → `sent` → `delivered`, y después se llena `leidoEn`	`submitted` → `sent` → `failed`, con el código `131026`

El +56222222244 es el teléfono del RUT de prueba 44444444-4. Úsalo para ensayar cómo responde tu sistema a una entrega fallida.

En prueba, el único canal de WhatsApp que existe es el canal de prueba de la plataforma. Su identificador va en la ruta, en lugar del channelId de tu canal real:

curl -X POST "https://api.redcumbre.cl/{tenantSlug}/canales/whatsapp/canal-whatsapp-de-prueba/enviar" \
  -H "Authorization: Bearer <tu API Key de prueba>" \
  -H "Content-Type: application/json" \
  -d '{
    "destinatario": "+56912345678",
    "templateName": "recordatorio_de_pago",
    "languageCode": "es",
    "componentes": {
      "cuerpo": {
        "variables": [
          { "posicion": 1, "valor": "María" },
          { "posicion": 2, "valor": "F-1024" },
          { "posicion": 3, "valor": "15-10-2026" }
        ]
      }
    }
  }'

Con otro identificador —también el de tu canal real— la respuesta es el mismo 404 de un canal que no existe. El canal de prueba tiene estas plantillas de ejemplo. Una plantilla que no está en la tabla responde igual que una plantilla que no existe, aunque exista en tu canal real:

`templateName`	`languageCode`	Cuerpo	Variables del cuerpo	Además
`pedido_en_camino`	`es`	Hola, tu pedido {{1}} va en camino.	1. Número del pedido	Encabezado con material
`recordatorio_de_pago`	`es`	Hola {{1}}, te recordamos que el documento {{2}} vence el {{3}}.	1. Nombre del cliente · 2. Folio del documento · 3. Fecha de vencimiento	—
`documento_disponible`	`es`	Hola {{1}}, tu documento está disponible. Ábrelo con el botón de abajo.	1. Nombre del destinatario	Botón de URL con variable

En la bandeja ves el cuerpo con tus variables puestas. Una variable que no enviaste queda escrita como {{n}}, para que veas qué faltó.

La configuración de autorizaciones de prueba

En prueba, el flujo de autorización está habilitado para toda empresa y usa esta configuración, no la de tu catálogo real. Así lo pruebas aunque no lo tengas habilitado en real, y probarlo no lo habilita en tu emisión real:

Parámetro	Valor en prueba
Flujo de autorización	Habilitado
Plazo de una solicitud antes de expirar	7 días (10.080 minutos), el mismo con que nace una configuración real
Roles a los que se avisa una solicitud	`SUPER-ADMIN` y `SUPERVISOR-VENTAS`

Credenciales del SII

En prueba no existe una credencial rechazada: ningún valor de prueba la provoca. Un emisor de prueba no usa la clave del SII, y «reintentar la credencial» sobre él responde como un reintento exitoso, con la credencial vigente. El rechazo de una credencial sólo ocurre en real.

Operaciones que responden distinto según el modo

Una operación que no tiene simulación responde 400 con OPERACION_NO_DISPONIBLE_EN_PRUEBA y el motivo. Hoy es el caso de crear una transacción de verificación PINRUT y de descargar el PDF de respaldo del SII de un documento.
Una acción de simulación llamada con una API Key real responde 400 con OPERACION_SOLO_EN_MODO_DE_PRUEBA: existe sólo en el modo de prueba.

Restaurar el modo de prueba

Un administrador de tu empresa puede restaurar el modo de prueba desde el panel, en Modo de prueba, o con redcumbre restaurar --confirmar <slug>. Restaurar borra todo lo que creaste en prueba y vuelve a cargar los datos de ejemplo. Conserva la configuración de tu endpoint de webhook de prueba y no reinicia el tope diario.

Cuánto tiempo se conserva lo que creas

Lo que creas en el modo de prueba se suprime a los 30 días de creado. Si algo que creaste después depende de ello, se suprime cuando vence lo último que depende, y nunca después de 60 días desde su creación. Restaurar el modo de prueba suprime en el acto todo lo que creaste. Al terminar el contrato, a lo que quede del modo de prueba se le aplica lo que venza primero entre su propio plazo y 30 días corridos desde el término. La supresión es definitiva: no se archiva. En las copias de respaldo, llega con su rotación ordinaria. Los datos precargados y la configuración de tu endpoint de webhook de prueba no se suprimen.

Usa los RUT de prueba del catálogo. No cargues datos de personas reales: el modo de prueba no los necesita.