Skip to main content

API vs SMTP

Mailtarget supports two integration paths to the same sending engine. Pick the one that matches what your application can do today.

Quick decision​

Use the API if...Use SMTP if...
You can make HTTP requests with JSON bodies.You already have an SMTP-aware mail stack you want to keep.
You need server-side templates with substitution data.You want a drop-in relay with one host and one port.
You want a transmissionId you can correlate to webhook events.Your application talks to localhost:25 or another relay today and you want to swap the destination.
You need attachments, custom headers, metadata, or per-recipient overrides in one call.You are integrating an off-the-shelf system (CMS, CRM, monitoring tool) that exposes SMTP settings only.
Latency matters and you want one round trip per send.You want minimum code change.

If both columns describe you, default to the API path. It gives you more control, better error reporting, and a cleaner reconciliation story with webhooks.

What the API path looks like​

POST https://transmission.mailtarget.co/v1/layang/transmissions
Authorization: Bearer <api_key>
Content-Type: application/json

{
  "subject": "Your receipt",
  "from":    { "email": "billing@yourcompany.com", "name": "Your Company" },
  "to":      [ { "email": "user@example.com" } ],
  "bodyHtml": "<p>Thanks for your order.</p>"
}

The response is a JSON object with a transmissionId. That ID is the handle you correlate to delivery events on the webhook side.

Read API Quickstart for the full first-send walkthrough, and the Transmission API reference for the complete request shape.

What the SMTP path looks like​

host:       smtp.mtrgt.net
port:       587
encryption: STARTTLS
username:   smtp_mt_injection
password:   <api_key with Send via SMTP permission>

Your application keeps speaking SMTP. The relay handles authentication, deliverability, and tracking. Read SMTP Quickstart for the verification command.

What you give up by choosing SMTP​

The SMTP path is the simpler integration. The trade-off is feature surface.

  • No structured response. SMTP returns a delivery acknowledgement, not a transmissionId. Reconciliation against webhook events is correlated by message ID and headers, not by a single ID returned at submit time.
  • No server-side templates. You build the message in your application and submit it whole.
  • No per-recipient substitution data in one call. You send one message at a time.
  • Limited metadata. Custom headers work; structured metadata for analytics requires the API path.

If those trade-offs are blocking, switch to the API path. The two paths can run side by side: keep your existing SMTP integration and adopt the API for new code paths.

What both paths share​

Both paths use the same authentication system, the same sending domain authentication, the same deliverability engine, and the same webhook events. Switching paths does not change your domain reputation or your reporting.