Sandbox Mode de SendGrid valida una solicitud a Mail Send API sin entregar el correo. No permite observar Inbox o Spam. Para medir la ubicación, realiza un envío real y permitido por tu ruta habitual a las direcciones de LDM. Mantén separados la validación, los eventos de envío y las carpetas observadas: una respuesta correcta de la API no demuestra una entrega.
«La API respondió correctamente, pero el buzón está vacío» puede describir un resultado esperado. Antes de revisar autenticación o asunto, identifica qué éxito registró la aplicación. Una solicitud válida, una presentación real aceptada y una copia encontrada son pruebas diferentes. Este procedimiento no presupone una integración nativa SendGrid–LDM.
No encontrar una copia tras una búsqueda correcta es distinto de un buzón inaccesible o una comprobación pendiente.
Qué comprueba Sandbox Mode
La opción se configura dentro de mail_settings y valida la estructura y los tipos de parámetros. Una validación correcta devuelve 200 OK; una solicitud correcta sin sandbox normalmente devuelve 202 Accepted. En sandbox no se entregan mensajes ni se generan eventos de Event Webhook o Email Activity. Consulta la documentación oficial.
Si incluyes template_id, la validación presupone que la plantilla contiene asunto y cuerpo, pero no verifica ese contenido. Por tanto, superar la validación tampoco demuestra que el mensaje final esté bien construido.
Usa esta etapa para detectar errores de integración. Revisa después el contenido renderizado y, cuando corresponda, realiza un envío externo limitado para observar las etapas siguientes.
Prepara el paso a un envío real
No desactives globalmente una protección de desarrollo para obtener un resultado. Identifica la solicitud o el trabajo aislado y limita expresamente sus destinatarios a las direcciones de la prueba actual.
Anota remitente, entorno, versión de plantilla, datos de personalización, seguimiento y cuenta o subusuario utilizado. No guardes claves API. Conserva suficientes detalles para reproducir la configuración sin incluir secretos en el informe.
Usa datos realistas y no confidenciales. Mantén las bajas y cabeceras obligatorias. Una plantilla promocional sin su pie habitual es un mensaje distinto y no representa bien la campaña prevista.
Esta guía está en español; la interfaz de LDM también está disponible en español. Los enlaces abren la interfaz en español.
Seis pasos para la prueba
1. Valida la solicitud prevista
Ejecuta la validación sandbox e investiga sus errores estructurales. Revisa por separado el resultado real de la plantilla con los mismos datos: asunto, alternativa de texto, enlaces importantes y secciones condicionales.
Identifica esta etapa como validación de solicitud y contenido. No la llames «entregado», aunque tu aplicación utilice esa palabra para cualquier respuesta HTTP correcta. Un registro preciso evita iniciar la investigación en una etapa equivocada.
2. Elige la ruta representativa
Si la aplicación utiliza Mail Send API, prueba ese mismo camino. Si normalmente envía por SMTP, conserva su ruta SMTP real. Una prueba API no sustituye automáticamente un trabajo SMTP con otra construcción del contenido y las cabeceras.
Mantén identidad del remitente, renderizado, tratamiento de enlaces y configuración relevante. Documenta cualquier diferencia deliberada. El objetivo es reproducir el comportamiento que quieres evaluar, no solo obtener una respuesta satisfactoria.
3. Crea una prueba independiente en LDM
Introduce el remitente real en Inbox Placement by LDM y obtén las direcciones actuales. Son temporales: no las importes a una audiencia permanente, calentamiento o secuencia que siga enviando después.
Confirma que la cuenta y el flujo de destinatarios permiten la prueba. No anules una supresión u otra restricción solo para conseguir un informe. Primero establece qué envío está autorizado en esa configuración.
4. Revisa la configuración efectiva
En Mail Send API, comprueba mail_settings.sandbox_mode.enable inmediatamente antes de presentar la solicitud. La referencia de Mail Send define un Boolean: false no equivale a la cadena "false". Utiliza la configuración admitida sin sandbox para ese envío específico.
Leer únicamente el código puede ocultar una sobrescritura del entorno. Inspecciona el valor efectivo sin mostrar credenciales. Mantén aislados los demás trabajos de desarrollo para que no alcancen destinatarios reales.
5. Envía un original y conserva referencias
Haz que la aplicación genere el mensaje directamente para las direcciones proporcionadas. No reenvíes una copia desde otro buzón, porque añadirías otra ruta y otro contexto.
Guarda resultado de presentación, hora, referencia del mensaje, revisión de plantilla e identificador del trabajo. Examina los eventos posteriores disponibles en tu cuenta. La presentación correcta inicia el seguimiento; no determina una carpeta.
6. Relaciona el resultado con el envío
Aplica la metodología de LDM. Ausente o desconocido no significa Spam. Promotions es una ubicación recibida diferente de Inbox principal y Spam. No combines observaciones confirmadas con comprobaciones incompletas.
La ventana de 24 horas observa la misma copia, sin volver a enviarla. Si después presentas otra versión de la plantilla, considérala un experimento independiente, no un punto posterior del primer mensaje.
Ejemplo hipotético: validación correcta, ninguna entrega
Un desarrollador añade destinatarios de prueba a una solicitud de staging. Recibe 200 OK, la aplicación registra «correo correcto» y no aparece ninguna copia. El equipo empieza a investigar el dominio.
La revisión revela que staging todavía activa Sandbox Mode. En este ejemplo hipotético, la ausencia se explica por una solicitud que no entrega. No hay evidencia de Spam. Conviene precisar el registro para que una validación no se confunda con una presentación real.
Después se ejecuta un envío autorizado y limitado. Supongamos que las copias aparecen en varias carpetas. Esas observaciones sí permiten estudiar placement, pero no convierten retroactivamente la validación inicial en una entrega fallida.
Investiga la etapa adecuada
Si el resultado real es inconcluso, parte de la aplicación: qué trabajo se ejecutó, qué presentó, si podía entregar y qué eventos posteriores existen. Después examina el buzón y la hora de observación. Un error de solicitud, un envío detenido y una consulta fallida son problemas distintos.
Evita cambiar plantilla, dominio, seguimiento y ruta simultáneamente si buscas aislar una causa. Probar una configuración completamente nueva puede ser útil, pero no identifica qué modificación explica una diferencia.
El panel describe esas copias bajo esas condiciones. No promete el resultado de toda tu audiencia ni demuestra que SendGrid o un elemento del contenido causaran la carpeta observada.
Preguntas frecuentes
¿Sandbox Mode muestra si el mensaje irá a Spam?
No. No existe una copia externa entregada que observar. Realiza otro envío permitido cuando la pregunta sea sobre una carpeta de un destinatario.
¿Por qué no aparecen eventos webhook en sandbox?
Es el comportamiento documentado. Comprueba la configuración efectiva antes de diagnosticar un fallo de instrumentación. La solicitud sandbox no verifica toda la cadena de eventos de entrega real.
¿La validación demuestra que mi plantilla dinámica es correcta?
No. Inspecciona aparte el renderizado y los datos utilizados. Una variable ausente, una sección condicional incorrecta o un enlace inesperado requieren revisión del contenido.
¿Puedo poner todas las direcciones en un único To visible?
Conserva la estructura del proceso real. Un conjunto visible no representa una aplicación que genera un mensaje individual por destinatario. Mantén también un alcance finito.
¿Qué significa que falte una copia y otra esté en Spam?
Son dos hechos distintos. Investiga la ausencia con registros y estado de observación. La copia confirmada en Spam no demuestra dónde terminó la otra.
Mide el mensaje real
Inicia una prueba de LDM cuando solicitud y contenido estén preparados. Conserva la distinción entre validación, presentación real y carpeta confirmada en el registro final.