Transactional Email

Email API vs SMTP Relay

Choose between a structured REST API and SMTP relay based on your application, migration constraints, and delivery troubleshooting needs.

Leadpush supports two paths for email triggered by an application:

  • the Email API for structured requests from application code
  • the SMTP relay for frameworks, mailers, and systems that already speak SMTP

Both paths require a verified sending domain, a verified sender address, and credentials scoped to the correct workspace. The best choice depends on how much of the existing mail path you want to change.

Email API vs SMTP at a glance

Decision areaEmail APISMTP relay
Best starting pointNew application integrations and teams that want a structured send responseExisting mailers, frameworks, legacy systems, and migrations with fewer changes
AuthenticationBearer API keyWorkspace SMTP username and password
EndpointPOST https://api.leadpush.io/v1/emailssmtp.leadpush.net on port 587
Message inputJSON fields for sender, recipients, subject, HTML, text, reply address, and headersA standard MIME message produced by the application mailer
Initial response202 Accepted with tracked message identifiersSMTP acceptance response from the relay
Official helpersNode.js and PHP SDKs, plus direct HTTP requestsAny backend framework or library that supports authenticated SMTP
Migration effortRequires mapping the existing send call to an API payloadOften begins with a credential and host change, followed by delivery validation

Choose the Email API when

  • you are building a new product email integration
  • the application benefits from structured validation and response data
  • you want to retain the returned message identifiers for support or delivery troubleshooting
  • your backend uses the official Node.js or PHP SDK
  • you want recipient, reply address, BCC, and custom header behavior to be explicit in the request payload

Start with the Send Email API reference, which includes cURL, Node.js, and PHP examples and documents queueing, recipient normalization, message identifiers, and asynchronous delivery behavior.

Choose SMTP relay when

  • your application already uses a reliable framework mailer
  • a legacy system cannot make the Leadpush REST request directly
  • you want to change the sending provider before refactoring the mailer
  • multiple applications already produce MIME messages that follow email standards
  • the fastest safe migration path is updating SMTP credentials and testing the existing message flow

Follow SMTP Setup for the required domain, sender, credential, and test send sequence. The Sending an Email guide includes working Node.js and swaks SMTP examples.

Shared delivery behavior to plan for

The integration method does not remove the need to plan the rest of the transactional email process:

  1. Verify the sending domain and exact sender address.
  2. Keep API or SMTP credentials in a secret manager on the server.
  3. Check suppressions before treating a missing email as a transport failure.
  4. Preserve correlation or application identifiers in supported custom headers.
  5. Monitor delivery, bounce, complaint, and failure signals after the initial API or SMTP acceptance.
  6. Test password reset, OTP, receipt, and account alert paths before sending live traffic.

A gradual migration pattern

Inventory the current mail path

List every sender, message type, template, custom header, suppression rule, callback, and environment that uses the existing provider.

Pick one message type with low risk

Move a controlled notification before an account recovery or authentication message. Keep the old path available during validation.

Choose API or SMTP for that path

Use the API when application changes are acceptable and structured responses are valuable. Use SMTP when preserving the current mailer reduces migration risk.

Validate message and delivery behavior

Confirm sender identity, personalization, links, headers, delivery events, suppressions, and the support steps used when a recipient reports a missing message.

Ramp traffic and repeat

Increase volume gradually, compare delivery outcomes, then migrate the next message type using the same checklist.

Connect delivery events to your application

Email acceptance is not the same as final delivery. Use webhook destinations and delivery history to connect important events to application or support workflows. The webhook monitoring and retry guide explains statuses, receiver failures, repeated delivery, idempotency, and manual retries.

Frequently asked questions

Explore this topic

Continue exploring this topic

Connect this guide to relevant product capabilities, implementation details, and practical email workflows.

ProductTransactional Email API & SMTP RelayExplore API and SMTP delivery for authentication, billing, alerts, and other product-triggered email.Developer guideSend Email APISend transactional email with a concrete API request and supported message fields.Knowledge baseSMTP SetupConfigure a sending domain, credentials, and a first SMTP delivery in the right order.Developer guideLeadpush SDKsConnect applications to Leadpush with an official SDK and implementation examples.Knowledge baseWebhook Monitoring, Retries, and IdempotencyInspect webhook attempts, troubleshoot receiver failures, deduplicate events, and retry failed deliveries.ComparisonCompare LeadpushCompare transactional and lifecycle email platforms, product fit, tradeoffs, and migration requirements.

Custom Email Headers

Use Leadpush custom email headers to tag transactional messages and control tracking behavior before delivery.

Template Studio

Learn how to use Template Studio, the Leadpush drag-and-drop email builder, for visual editing, previewing, publishing, blueprints, and reusable content workflows.