O Sandbox Mode do SendGrid valida uma requisição da Mail Send API sem entregar o e-mail. Para verificar Inbox ou Spam, faça um envio real permitido pela rota da sua aplicação aos endereços de teste do LDM. Separe a validação da requisição, os eventos de envio e a pasta observada: uma resposta de sucesso da API não comprova entrega.
“A API retornou sucesso, mas a caixa de teste está vazia” pode ser um comportamento esperado. Antes de alterar autenticação ou assunto, descubra qual sucesso foi registrado. Este procedimento combina validação e observação externa, sem pressupor integração nativa entre SendGrid e LDM.
Não encontrar uma cópia após uma busca concluída é diferente de uma caixa indisponível ou de uma verificação pendente.
O que o Sandbox Mode verifica
O SendGrid documenta esse modo como uma configuração de Mail Send dentro de mail_settings. Ele verifica a estrutura da requisição e os tipos dos parâmetros. Uma validação bem-sucedida retorna 200 OK; uma submissão bem-sucedida fora do sandbox normalmente retorna 202 Accepted.
Requisições em Sandbox Mode não entregam mensagens nem geram eventos em Event Webhook ou Email Activity. Há também uma limitação de conteúdo: quando a requisição inclui template_id, a validação pressupõe que o modelo contém assunto e corpo; não verifica esse conteúdo. Consulte a documentação oficial de Sandbox Mode.
Use a validação para localizar erros de integração. Depois confira o conteúdo gerado e, quando pertinente, faça um envio real controlado. São etapas complementares.
Prepare uma transição controlada
Identifique a requisição ou tarefa específica que fará o envio real e limite explicitamente seus destinatários. Não desative globalmente uma proteção do ambiente de desenvolvimento apenas para obter uma observação de pasta.
Registre remetente, ambiente, versão do modelo, dados de personalização, rastreamento e conta ou subusuário utilizado. Preserve informações suficientes para reproduzir o teste, sem incluir chaves de API no relatório.
Utilize dados fictícios representativos, sem informações privadas de clientes. Mantenha cabeçalhos e mecanismos obrigatórios de descadastro. Uma campanha sem seu rodapé habitual deixa de representar a mensagem planejada.
Seis etapas para executar a verificação
1. Valide a requisição prevista
Execute a validação em Sandbox Mode e resolva os problemas estruturais encontrados. Separadamente, revise o conteúdo produzido pelo modelo com os mesmos dados de teste: assunto, versão em texto, links e blocos condicionais.
Registre a etapa como validação da requisição e do conteúdo. Evite chamar qualquer resposta HTTP bem-sucedida de “entrega”, pois isso confunde o diagnóstico posterior.
2. Escolha a rota correspondente à produção
Se a aplicação usa a Mail Send API, teste esse caminho. Se utiliza SMTP, verifique sua rota SMTP real. Uma experiência pela API não substitui automaticamente um envio SMTP com outra composição de conteúdo ou cabeçalhos.
Preserve identidade do remetente, geração da mensagem, tratamento dos links e configurações relevantes. Anote diferenças intencionais para delimitar o que foi efetivamente avaliado.
3. Abra um teste separado no LDM
Informe o remetente real no LDM Inbox Placement e obtenha os endereços atuais. A interface do teste também está disponível em português.
Trate os destinatários como temporários. Não os importe para públicos permanentes, sistemas de aquecimento ou sequências contínuas. Respeite as permissões da conta e eventuais supressões; não contorne uma restrição somente para produzir um relatório.
4. Confira a configuração que permite a entrega
Na Mail Send API, inspecione o valor efetivo de mail_settings.sandbox_mode.enable imediatamente antes da submissão. A referência da API define um Boolean: false e a string "false" não são equivalentes. Utilize a configuração suportada fora do sandbox para aquele envio específico.
O código-fonte sozinho pode não revelar uma substituição de configuração do ambiente. Confira os valores realmente aplicados sem expor credenciais e mantenha as tarefas não relacionadas isoladas.
5. Envie um original e preserve os identificadores
Faça a aplicação gerar a mensagem diretamente para os destinatários fornecidos. Não encaminhe uma cópia de outra caixa postal, pois isso introduz outro trajeto e outro contexto.
Guarde resultado da submissão, horário, referência disponível da mensagem, versão do modelo e identificador da tarefa. Consulte os eventos posteriores disponíveis na conta. A submissão aceita inicia o rastreamento; não mede a pasta de destino.
6. Leia a pasta junto com o registro de envio
Aplique a metodologia LDM. Missing e unknown não significam Spam. Promoções é um local de recebimento, distinto da caixa principal e de Spam. Preserve separadamente observações confirmadas e verificações incompletas.
A janela de 24 horas acompanha a mesma cópia recebida, sem reenviar a mensagem. Um modelo revisado e enviado posteriormente pertence a outro experimento, não a uma nova observação da primeira cópia.
Exemplo hipotético: validação aprovada, sem entrega
Imagine que um desenvolvedor acrescente destinatários de teste a uma requisição de homologação. Recebe 200 OK, a aplicação registra “e-mail enviado com sucesso”, mas nenhuma mensagem aparece nos destinatários. A equipe começa a investigar o domínio.
Uma inspeção revela que o ambiente ainda ativa Sandbox Mode. Neste exemplo hipotético, a ausência decorre de uma requisição sem entrega; não existe evidência de Spam. O registro da aplicação precisa distinguir validação e submissão real.
O desenvolvedor então prepara um envio separado, permitido e limitado aos destinatários previstos. Se as cópias aparecerem em pastas diferentes, essas observações poderão orientar a investigação. Elas não transformam retroativamente a primeira validação em uma entrega malsucedida.
Investigue a etapa correta
Quando o resultado for inconclusivo, verifique a tarefa executada, o conteúdo submetido, a permissão para entrega e os eventos disponíveis. Depois confira a observação externa e seu horário. Erro de requisição, envio impedido e falha de observação são situações diferentes.
Evite alterar modelo, domínio, rastreamento e rota ao mesmo tempo se deseja identificar uma causa. Um teste de toda a nova configuração pode ser útil, mas não isola o efeito de cada mudança. O resultado descreve as cópias observadas, sem prometer o comportamento de toda a audiência.
Perguntas frequentes
O Sandbox Mode mostra se a mensagem vai para Spam?
Não. Não existe uma cópia entregue para observar. Faça um envio real separado e permitido quando a pergunta tratar da pasta escolhida pela caixa destinatária.
Por que minha requisição de sandbox não gera eventos de webhook?
Esse comportamento é documentado. Confira a configuração efetiva antes de concluir que há falha na coleta de eventos. Uma requisição de sandbox não avalia todo o processamento de eventos de um envio real.
A validação aprovada confirma que meu modelo dinâmico está correto?
Não. Revise o conteúdo gerado e os dados de teste. Personalização ausente, blocos condicionais inadequados ou links incorretos exigem inspeção própria, independentemente da validade da requisição.
Devo colocar todos os endereços de teste em um único campo To visível?
Preserve a estrutura do envio real. Vários destinatários visíveis não representam uma aplicação que normalmente gera uma mensagem individual por pessoa. Mantenha a verificação limitada ao conjunto previsto.
E se uma cópia estiver ausente e outra aparecer em Spam?
Registre os fatos separadamente. Investigue a ausente com os registros de envio e o estado da observação. A confirmação de Spam em uma cópia não determina o destino da outra.
Observe a mensagem real após validar
Inicie um teste LDM quando a requisição e o conteúdo estiverem prontos. Preserve a distinção entre requisição válida, submissão real e localização confirmada na caixa postal.