Ir al contenido

Entornos y modo sandbox

Antes de escribir la primera llamada conviene despejar esto, porque no funciona como en la mayoría de las APIs.

https://api.redcumbre.cl

No hay sandbox.redcumbre.cl, ni un path /sandbox, ni un subdominio de staging para integradores. Todas las llamadas —de prueba y de producción— van al mismo host.

Lo que decide si una llamada es de prueba o real no es la URL: es la credencial. Cada API Key se crea marcada como sandbox o no, y eso no se puede cambiar después.

Con una key de sandbox:

  • No se llama a servicios externos reales. Nada llega al SII. Las respuestas se resuelven con datos de prueba.

  • No se genera facturación. Ningún evento de billing se emite.

  • La respuesta viene marcada con sandbox: true, así tu código puede distinguirlo sin depender de qué key cargó el entorno.

  • Los documentos emitidos llevan folio con prefijo SANDBOX-. Es la única marca persistente: si reprocesas un webhook viejo, el folio te dice de dónde salió.

  • No sale ningún correo a terceros. Ni la boleta recién emitida, ni el comprobante de una anulación, ni un reenvío manual del PDF desde el panel. La supresión se decide por el folio del documento, no por la credencial que pide el envío: una boleta emitida en sandbox nunca despacha correo, aunque el reenvío lo pida después un usuario del panel con su sesión normal. Los endpoints de envío responden con su contrato de siempre y sandbox: true.

    Los webhooks sí se emiten en sandbox: son la mitad de lo que necesitas ejercitar. Lo que no ocurre es la comunicación con una persona real.

Para pasar a producción se crea una API Key nueva. No hay un endpoint ni una opción de panel que convierta tu key de pruebas en una key real.

No es una omisión, es un control deliberado: el secreto de una key de pruebas ya está repartido por los entornos del integrador, y muy probablemente commiteado en algún repositorio. Si ese flag fuera editable, esa credencial ya expuesta pasaría a emitir documentos reales ante el SII y a generar cobros, sin rotar el secreto y sin que nadie se entere.

Las dos keys conviven en el mismo tenant. No son dos cuentas ni dos contratos: es una credencial más.

Ventana de terminal
curl -s https://api.redcumbre.cl/{tenantSlug}/whoami \
-H "Authorization: Bearer $REDCUMBRE_API_KEY"
{
"success": true,
"data": {
"tenant": { "slug": "tu-tenant", "nombre": "Tu Empresa SpA" },
"credencial": { "tipo": "api_key", "nombre": "Integración ERP", "roles": ["FULL-API"], "sandbox": true },
"timestamp": "2026-08-18T14:32:10.512Z"
}
}

Es la primera llamada que conviene hacer al integrar: confirma de una vez que la key es válida, que el tenantSlug es el correcto, qué roles tienes y si estás en sandbox.

Vas a encontrar ese dominio si buscas. Es el entorno interno de desarrollo de REDCUMBRE, no está disponible para integradores y su contenido cambia sin aviso. La especificación OpenAPI de producción no lo declara como servidor, justamente para que nadie lo tome por un sandbox público.

Para probar, la vía es una API Key de sandbox contra la URL de producción.

Estas cosas no se resuelven por API y ningún asistente las va a poder hacer por vos:

ParaNecesitás
Llamar cualquier endpointUna API Key (de sandbox o real) emitida para tu tenant
Usar un módulo concretoQue el servicio esté habilitado en tu tenant
Emitir documentos tributariosUn emisor DTE configurado, con certificado digital vigente y folios CAF

Escribe a tu contacto en REDCUMBRE para cualquiera de las tres.