Skip to main content
El sandbox es un ambiente aislado donde puedes probar toda tu integración —registrar empresas, subir CSD, timbrar, cancelar, descargar XML/PDF— sin generar CFDIs con validez fiscal y sin costo.
Los CFDIs timbrados en el sandbox son simulados: llevan un UUID y un Timbre Fiscal Digital con estructura completa, pero no tienen validez fiscal ante el SAT y no se reportan a ningún sistema del SAT. No los uses para efectos fiscales reales.

Base URL

El sandbox vive en un host y una base de datos independientes de producción. Tus datos, folios y credenciales de sandbox no se comparten con producción. Para cambiar de ambiente solo cambias la base URL y usas la API key del ambiente correspondiente. Una API key de producción no funciona en el sandbox, y viceversa.

Obtén tus credenciales de sandbox

Solicítalas en ipsofactura.com/contacto. Te entregamos una API key de sandbox dedicada, sin cupo de timbres y sin costo. Los límites de tasa por minuto son los mismos que en producción.

¿Qué es un CSD?

El Certificado de Sello Digital (CSD) es la credencial con la que el SAT autoriza a un contribuyente a sellar (firmar) sus CFDIs. Son tres cosas que envías al registrarlo: En producción subes el CSD real de tu empresa (el que descargas del SAT con tu e.firma). En el sandbox NO uses tu CSD real.
El sandbox rechaza CSD de producción. Usa un CSD de prueba del SAT (abajo). Además, el RFC de tu empresa emisora debe coincidir con el RFC del CSD que subas.
Como los CSD de prueba del SAT son públicos y compartidos, en el sandbox el mismo número de certificado puede registrarse en varias empresas (la unicidad es por empresa). En producción el número de certificado es único a nivel global.

CSD de prueba (descarga)

El SAT publica CSD de prueba gratuitos para desarrollo. Producen CFDIs simulados, sin validez fiscal. Te dejamos los más usados listos para descargar (contraseña 12345678a en todos):

Descargar kit CSD de prueba (.zip)

Contiene EKU9003173C9.cer / .key (moral), CACX7605101P8.cer / .key (física) y un archivo LEEME.txt. Contraseña de las llaves: 12345678a.
numero_certificado y fecha_fin se leen del propio .cer y se validan contra él. fecha_fin va en formato YYYY-MM-DD (si envías un date-time ISO 8601, la hora se descarta). Al capturar la razón social usa el nombre sin el sufijo de régimen de capital (ESCUELA KEMPER URGATE, no ... SA DE CV), tal como lo valida el SAT.

Convertir a Base64

certificado_cer_base64 y llave_key_base64 van en Base64, en una sola línea:

Registrar el CSD

cURL

Flujo de prueba

1

Registra el CSD de prueba

Sube el .cer y .key de prueba del SAT a tu empresa de sandbox, igual que en producción pero contra la base URL del sandbox.
2

Timbra un CFDI

Envía tu CFDI como en producción. El sandbox ejecuta las validaciones y devuelve un timbre simulado.
cURL
3

Verifica la respuesta

Una respuesta exitosa del sandbox incluye el campo sandbox: true. Este campo no aparece en producción, así que sirve para confirmar contra qué ambiente estás integrando.

Qué valida el sandbox y qué no

El sandbox timbra con un PAC simulado: valida el XSD del SAT (CFDI 4.0 y Pagos 2.0) y las reglas propias de Ipsofactura, pero no aplica la matriz de reglas de negocio del SAT que sí aplica el PAC de producción. Un CFDI aceptado en sandbox puede ser rechazado en producción con 400 VALIDATION_ERROR y su sat_code.
El sandbox no sirve como validador fiscal previo. Un 201 del sandbox confirma que tu integración habla bien con la API (autenticación, contrato, forma del XML/JSON, cuadre de totales), no que el SAT aceptaría el comprobante. Las reglas de la tabla “No valida” se descubren por primera vez en producción, con el timbre consumido: sólo un PAC real puede ejercitarlas.

Sí valida (igual que producción)

Estas reglas viven en Ipsofactura, no en el PAC, así que responden lo mismo en ambos ambientes:
  • Estructura: en POST /cfdi/timbrar-xml, el XSD completo del SAT, incluidos los catálogos que el propio esquema enumera (ClaveProdServ, ClaveUnidad, UsoCFDI, RegimenFiscal, FormaPago, …). En POST /cfdi/timbrar (JSON) se valida el contrato del request, no el XSD: una clave_prod_serv inexistente sólo la rechaza el PAC de producción.
  • Cuadre del comprobante: Total = SubTotal − Descuento + Traslados − Retenidos, TotalImpuestosTrasladados / TotalImpuestosRetenidos contra la suma de los conceptos, descuento no mayor que el importe (CALCULATION_MISMATCH, DESCUENTO_EXCEEDS_IMPORTE).
  • Campos obligatorios por tipo: MetodoPago y FormaPago en ingresos y egresos.
  • Complemento de pago: sólo contra facturas PPD; saldo pendiente y parcialidades consistentes con los pagos ya timbrados; en POST /cfdi/complemento-pago, imp_saldo_ant − imp_pagado = imp_saldo_insoluto cuando envías los saldos.
  • Receptor: UsoCFDI aplicable al RegimenFiscal del receptor (CFDI40161, CFDI40157), régimen acorde al tipo de persona del RFC, y UsoCFDI = S01 para el receptor extranjero XEXX010101000.

No valida (producción sí las rechaza)

Todo esto se timbra con 201 en el sandbox y lo rechaza el PAC de producción: No necesitas replicar estas reglas de tu lado: producción las rechaza con 400 y sat_code antes de consumir un timbre. Lo que sí conviene es que tu manejo de errores no dependa de haberlas visto fallar en sandbox. Cuando una validación falla, el sandbox responde con el mismo formato de error que producción, incluyendo el código CFDIxxxxx en sat_code y en el mensaje:

RFCs mágicos

Para forzar escenarios de error de forma determinista (al estilo de las tarjetas de prueba de Stripe), usa estos RFC de receptor reservados en el sandbox: Cualquier otro RFC válido sigue el flujo normal de validación descrito arriba.

En qué rutas se disparan

Cada ruta lee el RFC del escenario del campo que tiene a mano: Los dos casos con rfc_receptor existen porque esas rutas no tienen receptor propio que leer:
  • En POST /cfdi/complemento-pago el receptor del CFDI tipo P lo determina la factura que liquida (el SAT exige que coincidan), así que rfc_receptor no se timbra — sólo selecciona el escenario, y en producción se ignora. Con él puedes ejercitar ACCOUNT_SUSPENDED, CERTIFICATE_EXPIRED, CERTIFICATE_NOT_YET_VALID, CERTIFICATE_REVOKED, TRIAL_LIMIT_EXCEEDED, el error de validación, el timeout y el timbrado tardío, con el mismo código que responde POST /cfdi/timbrar.
  • En POST /cfdi/cancelar por folio_fiscal es un dato real —el receptor del comprobante ajeno, lo único que sólo tú puedes decirnos— y queda registrado en la fila. Es lo que permite ensayar una cancelación diferida (SBX010101PRO / SBX010101RCH) sobre un CFDI externo. Ver Cancelación de CFDI.
Forzar un escenario en el complemento de pago
TRIAL_LIMIT_EXCEEDED sí aplica al complemento de pago: producción cobra el timbre de un REP contra el mismo cupo del periodo de prueba.
El RFC de timeout es SBX010101TMO, terminado en la letra O (de timeout), no en cero. SBX010101TM0 no es un RFC mágico: se procesa como un receptor normal y el timbrado responde 201 sin aviso alguno.
Los códigos de la columna central son los reales de producción — el sandbox no inventa códigos propios. Lo que valides aquí es exactamente lo que recibirás en producción; ver Errores.

Escenarios del alta del CSD

SBX010101NOV y SBX010101SUS también funcionan como RFC de la empresa emisora, para probar los dos escenarios que ocurren al registrar el CSD y no al timbrar. Crea una empresa con ese RFC (POST /empresas) y súbele un CSD de prueba (POST /empresas/{empresa_id}/certificados):
Los RFC reservados nunca viajan en rfc_emisor: ese campo se valida contra el patrón de RFC del SAT (el último carácter debe ser dígito o A), así que un rfc_emisor terminado en letra responde 400 INVALID_RFC_FORMAT antes de cualquier otra cosa. Por eso un escenario sólo se puede forzar en las rutas de la tabla de arriba, que sí leen un RFC: un GET no lleva ninguno, y ahí no hay nada que disparar. En producción la suspensión de la cuenta la decide la autenticación, en todas las rutas.
Con SBX010101PRO, SBX010101RCH y SBX010101LAT no necesitas esperar frente a la terminal: suscribe un webhook (cfdi.cancelado, cfdi.cancelacion_rechazada, cfdi.timbrado o pago.timbrado) y el desenlace te llega solo cuando el barrido de sandbox lo resuelve. Ver también Recuperación tras timeout para el flujo completo de STAMPING_OUTCOME_UNKNOWN.

Diferencias con producción

  • Los CFDIs no tienen validez fiscal y no se reportan al SAT.
  • Sólo valida el XSD y las reglas propias de Ipsofactura, no la matriz de reglas del SAT (ver Qué valida el sandbox y qué no).
  • Solo se aceptan CSD de prueba del SAT (los de producción se rechazan).
  • Las respuestas de timbrado incluyen sandbox: true; los sellos son marcadores SANDBOX_… y no hay material criptográfico verificable.
  • Es gratis y sin cupo de timbres; los límites de tasa por minuto son los mismos.
  • Los documentos se descartan a los 15 minutos. En producción el XML y el PDF persisten y GET /cfdi/{id}/xml genera una URL nueva cada vez; en sandbox el almacenamiento es temporal: pasados 15 minutos desde el timbrado, el endpoint responde 404 DOCUMENT_NOT_AVAILABLE y el archivo ya no se puede recuperar. Descarga el XML en cuanto timbres. La fila del CFDI (GET /cfdi/{id}, GET /cfdi) sí se conserva.
  • Las URLs de descarga (xml_url / pdf_url) funcionan igual que en producción: no exigen API key y valen 15 minutos, como una SAS de Azure. Quien tenga la URL puede descargar el documento mientras siga vigente; no la guardes ni la compartas. Ver Datos y retención.
  • El UUID del sandbox no se puede verificar en el portal “Verifica tus facturas” del SAT.