Route · Email API
API de e-mail
Envie OTPs, redefinições de senha, alertas de conta, faturas e mensagens de ciclo de vida a partir de uma única API. A Sendarix foi desenhada para comportamento previsível em escala, não integrações frágeis.
# Enviar email crítico por uma routing policy curl -sS -X POST 'https://app.sendarix.com/v1/email/send' \ -H 'Content-Type: application/json' \ -H 'X-API-Key: YOUR_API_KEY' \ -H 'Idempotency-Key: otp_8842' \ -d '{"to":"user@acme.com","template":"password_reset","routing_policy":"transactional-critical"}'
const sendarix = require("sendarix")(process.env.SENDARIX_KEY); await sendarix.email.send({ to: "user@acme.com", template: "password_reset", routingPolicy: "transactional-critical", idempotencyKey: "otp_8842" });
# SMTP drop-in — mantenha sua integração e ganhe um control plane host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Um contrato estável
Uma API prática para equipes que entregam rápido
Autentique solicitações, envie mensagens e acompanhe resultados em um pipeline consistente. Cada envio pode ser observado por meio de logs, eventos e webhooks.
UI representativa do produto — dados ilustrativos, não métricas reais de clientes.
O que você obtém
A API é intencionalmente direta: criar e enviar mensagens, inspecionar resultados e automatizar reações. Isso ajuda equipes de produto a avançar mais rápido sem abrir mão da confiabilidade.
Integração REST rápida
Padrões claros de requisição/resposta e comportamento previsível para serviços de backend modernos e ferramentas internas.
Rastreamento do ciclo de vida da mensagem
Acompanhe estados aceitos, entregues, com falha (bounce) e reclamações para que o produto reaja em tempo real.
Visibilidade operacional
Logs pesquisáveis e fluxos de eventos reduzem o tempo de solução quando usuários relatam problemas de entrega.
Escale sem reescrever tudo
De cargas iniciais a fluxos de alto volume, mantenha um único contrato de API conforme o volume cresce.
Injeção de dados em modelos
Passe variáveis dinâmicas de forma organizada para que modelos transacionais permaneçam consistentes entre produtos.
Padrões de envio idempotentes
Evite envios duplicados em cenários de nova tentativa com estratégias determinísticas de tratamento de requisições.
Fluxo típico da API
Um padrão simples que sua equipe pode implementar uma vez e reutilizar em todos os cenários transacionais.
1. Enviar solicitação
Seu serviço envia o payload com destinatário, dados do modelo e metadados.
2. Validar e enfileirar
Verificações de entrada, lógica de supressão e enfileiramento ocorrem antes da etapa de entrega.
3. Entregar
As mensagens são roteadas para provedores de destino com comportamento de envio controlado.
4. Consumir eventos
Use webhooks e logs para atualizar o estado do produto e acionar automações downstream.
Perguntas frequentes
Podemos usar API e SMTP juntos?
Sim. Muitas equipes usam a API para fluxos de aplicação e SMTP para sistemas legados durante a migração.
Recebemos dados de evento para cada mensagem?
Sim. Eventos de entrega, falha (bounce) e reclamação estão disponíveis para fluxos operacionais e de produto.
É adequado para tráfego de alto volume?
Sim. O mesmo modelo de API é usado desde fases de baixo volume até envio sustentado em alto volume.
Precisamos de SPF, DKIM e DMARC para envio via API?
Autenticar o domínio de envio é altamente recomendado. Melhora como os provedores de caixa de entrada avaliam seu e-mail e é uma expectativa básica para tráfego em produção.
Como funcionam chaves de API e permissões?
Você pode emitir chaves para diferentes ambientes ou serviços e restringir o que cada chave pode fazer, mantendo staging, CI e produção isolados.
O que acontece se nossa integração enviar solicitações inválidas ou duplicadas?
A API retorna erros de validação claros para payloads incorretos. Para novas tentativas, use identificadores estáveis na camada de aplicativo para não enviar duas vezes o mesmo e-mail voltado ao usuário.
Podemos correlacionar chamadas de API com a entrega downstream?
Sim. Identificadores de mensagem e linhas do tempo de eventos permitem ligar um envio específico da API a resultados aceitos, entregues, com falha ou adiados.
A API de e-mail é adequada para redefinições de senha e códigos OTP?
Sim. Esses fluxos são casos transacionais clássicos: expectativa de baixa latência, alta necessidade de visibilidade e acoplamento forte aos sistemas de autenticação ou risco.
Devemos usar apenas HTTPS para o tráfego da API?
Sim. TLS protege credenciais e metadados de mensagens em trânsito. Trate os endpoints da API como qualquer outra superfície de produção que carrega segredos.
What is the request rate limit on the Email API?
Rate limits vary by plan. Standard plans allow 1,000 requests/minute; enterprise plans support higher throughput. Rate limit headers are included in every response (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). Exceeding the limit returns 429 Too Many Requests.
How do we handle API failures gracefully in our application?
Implement exponential backoff with jitter for retries. Treat 429 as a signal to slow down, 5xx as transient errors to retry, and 4xx (except 429) as permanent failures that should not retry. Store the message_id from successful submissions to correlate with downstream webhook events.
What is the maximum message size via API?
Messages up to 50MB total payload are accepted. For files larger than 25MB, Sendarix recommends hosting files externally and including a signed download link in the email body rather than attaching directly. Some mail servers reject messages exceeding 25MB.
Can we schedule email delivery for a future time?
Yes. Pass a scheduled_time parameter (ISO 8601 UTC timestamp) in your API request. Messages are queued and delivered at the specified time. Scheduled messages can be cancelled before delivery by calling the message cancel endpoint with the message_id.
How do we handle unsubscribe programmatically via the API?
The API provides /unsubscribes endpoints for managing suppression records. When a user unsubscribes, add them via the API to prevent future sends to that address. This integrates with the email webhooks unsubscribe event for automatic suppression list updates.
What response codes should our retry logic handle?
Handle these specifically: 200 OK (success, no retry), 400 Bad Request (invalid payload, fix before retry), 401 Unauthorized (invalid API key, do not retry), 422 Unprocessable Entity (validation error, fix payload), 429 Too Many Requests (rate limited, retry after X-RateLimit-Reset), 500 Internal Server Error (transient, retry with backoff).
Produtos relacionados
Protege email crítico en cada tenant.
Mueve tu stream más crítico a Sendarix esta semana. Deja todo lo demás exactamente donde está.
