Sandbox

Sandbox es un entorno de pruebas aislado que te permite probar B2Brouter (emitir facturas, enviar documentos, testear la API) sin tocar datos reales, destinatarios reales ni el contador de transacciones de tu suscripción.

Qué es el Sandbox

• Un espacio de trabajo autónomo con datos separados (facturas, contactos, productos, plantillas, claves de API).
• Te permite hacer pruebas de extremo a extremo antes de contratar un plan de pago.
• Sirve para validar la integración con la API antes de desplegar a producción.
• Ideal para formación, demos y pruebas de concepto.

Comportamiento de red simulado. Por defecto, los envíos al sandbox tienen éxito y el documento llega a su estado final (equivalente a producción). Además, el sandbox puede reproducir el ciclo de vida completo de salida, incluyendo rechazos y errores de red, cuando envías a uno de los destinatarios de test documentados más abajo. Ningún documento sale nunca a la red real: todo el ciclo se simula dentro de B2Brouter.

Primeros pasos

Crear un Sandbox (interfaz web)

1. Inicia sesión en B2Brouter.
2. Haz clic en el botón Developers (icono de rayo).
3. Haz clic en Create Sandbox.
4. Ponle un nombre al sandbox.
5. Máximo 5 sandboxes por cuenta / grupo de integración.

Entrar y salir

• Haz clic en el icono de apertura (↗) para entrar en modo sandbox.
• Mientras estés en él, aparece un marco morado en todas las páginas.
• Haz clic en Exit Sandbox para volver a producción.

Usar la API en el Sandbox

El enrutamiento de la API se hace íntegramente por la clave:

• No hace falta ninguna URL ni subdominio de sandbox separado.
• Usa la base de API estándar de B2Brouter: https://api.b2brouter.net/.
• Las claves de producción empiezan por prod_ (o sin prefijo, por compatibilidad).
• Las claves de sandbox empiezan por test_.

Pasa la clave de sandbox mediante la cabecera X-B2B-API-Key o el parámetro de consulta api_key.

Ciclo de vida de los documentos

Los documentos siguen el mismo ciclo de vida que en producción. Con un destinatario normal, el envío llega hasta:

draft → sent → registered

Con un destinatario de test (ver más abajo), el sandbox continúa el ciclo según el escenario asociado, de manera asíncrona (las transiciones llegan en pocos segundos), para que puedas testear cómo tu sistema gestiona cada resultado:

• Registrado correctamente: sent → registered
• Rechazado: sent → registered → refused
• Error de red (destinatario no registrado): sent → error, con error_code = PEPPOL_NO_RECEIVER

Como las transiciones son asíncronas, si haces polling puedes ver los estados intermedios en sucesión rápida; tu código debe tolerar recibirlos encadenados. Los webhooks se disparan en cada transición, igual que en producción.

Simular respuestas de la red (destinatarios de test)

Para probar cómo reacciona tu sistema ante un rechazo o un error de red, envía a uno de los destinatarios de test predefinidos. Funcionan como test cards: el resultado está determinado por el destinatario, no por ningún parámetro especial. Tu código de envío se ejecuta exactamente igual que en producción.

Cada sandbox nuevo ya incluye estos contactos creados automáticamente (búscalos en tu lista de contactos), y también un canal PEPPOL activo, de manera que puedes enviar sin ninguna configuración previa.

Contacto de test	Canal	Esquema	Identificador (XIN)	Resultado simulado
Test PEPPOL — Registered	PEPPOL	GLN (0088)	9508397101047	sent → registered
Test PEPPOL — Refused	PEPPOL	GLN (0088)	9506215594996	sent → registered → refused
Test PEPPOL — No receiver	PEPPOL	GLN (0088)	9500047420799	sent → error (PEPPOL_NO_RECEIVER)

También puedes crear tus propios contactos con uno de estos identificadores: el sandbox reconoce el resultado por el identificador, no por el contacto concreto.

Cualquier otro destinatario (no listado aquí) sigue el camino por defecto y llega a sent/registered con éxito.

Alcance actual de la simulación

El ciclo de vida enriquecido (registrado/rechazado/error) está disponible para facturas por PEPPOL. Otros tipos de documento y canales completan con éxito (sent), y algunos casos solo distinguen éxito/error. Todavía no se simulan: la recepción de documentos entrantes, las respuestas de pedidos (Order response), ni los artefactos de respuesta de las autoridades fiscales (CSV/UPO). Estos llegarán en fases posteriores.

Qué se simula (no es real)

• No se envían emails desde el sandbox.
• Sin tráfico real de PEPPOL, ningún documento atraviesa la red PEPPOL y nunca se consulta el SMP real. El registro del destinatario y el ciclo de vida de la red se simulan íntegramente dentro de B2Brouter.
• Sin envíos reales a autoridades fiscales, SII, TicketBAI, Verifactu, Chorus y ZATCA se enrutan a los endpoints de test de la autoridad o se omiten.
• No se procesan pagos.

Marca de agua en los documentos

Las facturas y presupuestos descargados llevan una marca de agua clara: “No válida — Factura de prueba generada desde el Sandbox de B2Brouter”.

Limitaciones

No disponible en el Sandbox:

• Entrega real de documentos a PEPPOL, email, B2Bconnector o SFTP.
• Procesamiento real de pagos.
• Comprobaciones de verificación de autoridades fiscales.
• Pestaña de Conexiones (Transport) desactivada. El canal PEPPOL de pruebas ya viene configurado automáticamente: no hace falta gestionarlo para poder enviar a los destinatarios de test.
• Canales B2Bconnector y SFTP.
• Funciones de cierre de cuenta.

Otras restricciones:

• Los cambios de perfil (nombre, contraseña, 2FA) deben hacerse en producción.
• Las claves de API no cruzan entornos (las claves test_ solo funcionan en el sandbox).
• No se pueden clonar datos de producción al sandbox con un solo clic.

Webhooks

Los webhooks se disparan desde el sandbox de manera intencionada, ya que la entrega de webhooks es una de las cosas que los integradores necesitan probar. Los webhooks de sandbox y de producción son independientes y se configuran por separado.

Diferencias clave respecto a producción

• La identidad (usuario, contraseña, 2FA) se comparte entre entornos.
• El resto de datos están aislados.
• La actividad en el sandbox no consume cuota de suscripción.
• Todas las funciones a nivel de API están disponibles independientemente del plan contratado.