Sending mail

Longbridge Email sends transactional mail from any address at a send-verified domain. There are two front doors — an HTTPS API and plain SMTP — and one pipeline behind them, so both get identical verification, suppression, quota, and delivery events. Pick whichever suits the code you’re sending from.

Early access. Email is being rolled out behind an Org flag. If you don’t see it in the Console, it isn’t enabled for your organization yet.

Before you can send, the domain’s Sending state must read verified (see Configuring DNS) and you need a send key. The from address must belong to a send-verified domain the key is allowed to use.

Send over the HTTPS API

POST to /v1/email/send on your Org’s Email API host (api.email.lngbrdg.com), authenticating with the send key as a bearer token:

curl https://api.email.lngbrdg.com/v1/email/send \
  -H "Authorization: Bearer lpk_a1b2c3d4.9f8e7d6c5b4a39281706f5e4d3c2b1a0" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "receipts@example.com",
    "to": ["customer@their-domain.com"],
    "subject": "Your receipt",
    "text": "Thanks for your order.",
    "html": "<p>Thanks for your order.</p>"
  }'

The request body

Field	Type	Notes
from	string	An address at a send-verified domain the key may use. Required.
to	string[]	Recipients. Required.
cc, bcc	string[]	Additional recipients. Optional.
replyTo	string	Sets the Reply-To header. Optional.
subject	string	The subject line.
text	string	The plain-text body. Provide text, html, or both.
html	string	The HTML body.
headers	object	Extra headers — X-* and threading/list headers only. Optional.
attachments	object[]	Each is { filename, contentType, content }, where content is base64. Optional.

Recipients across to, cc, and bcc count toward the 50-recipient limit; the raw message may be up to 10 MiB.

Idempotency

Pass an Idempotency-Key header to make a retry safe. A first request with a given key is accepted (202) and remembered; a replay of the same key returns 200 with the original message id instead of sending again. Use it whenever a network blip might make your client retry a send.

Send over SMTP

Point any SMTP client at smtp.lngbrdg.com on port 587 (STARTTLS) or 465 (implicit TLS). Authenticate with AUTH PLAIN or AUTH LOGIN: the username is the key id (lpk_…, the part before the dot) and the password is the whole send-key secret.

Host:      smtp.lngbrdg.com
Port:      587            # STARTTLS  (or 465 for implicit TLS)
Username:  lpk_a1b2c3d4
Password:  lpk_a1b2c3d4.9f8e7d6c5b4a39281706f5e4d3c2b1a0

The envelope RCPT TO addresses are the destinations; the header From must be an address at a send-verified domain. SMTP sends hit the same gates as the API, mapped onto SMTP reply codes — a suppressed recipient comes back as 550 5.1.8 naming the address, a paused Org as 554, an over-quota send as 452 4.5.3.

SMTP exists so legacy software and off-the-shelf mailers can send without code changes. If you’re writing the integration yourself, the HTTPS API gives you structured errors and idempotency; reach for SMTP when the sender is something you can only configure, not program.

What “accepted” means

A 202 Accepted — or a clean SMTP 250 — means the message is durably enqueued and will be delivered. It does not mean it reached the inbox. Longbridge takes custody at accept, then works the message toward the mailbox provider with retries; the outcome arrives asynchronously as a delivery event.

A send can be rejected at accept, before it ever enters the queue:

Reason	API	Meaning
Unverified domain or key restriction	403	The from domain isn’t send-verified, or the key may not send from it.
Suppressed recipients	400	One or more recipients are on your suppression list; the response lists suppressedAddresses.
Over quota	429	You’ve hit the daily send quota; a Retry-After header says when to try again.
Sending paused	403	Your Org’s sending is paused after crossing a bounce or complaint threshold.
Message too large	413	The raw message exceeds 10 MiB.
Too many / no recipients	400	Over 50 recipients, or none.

A rejected send is never silently dropped — you always get a status and a reason.

Follow delivery through events

Each accepted message moves through states you can watch two ways: the message log in the Console (and via lbr email message), and webhook events if you’ve configured an endpoint. The delivery events are:

• email.sent — handed off to the mailbox provider.
• email.delivered — the provider accepted it for the recipient.
• email.bounced — delivery failed. A permanent bounce also suppresses the address; a transient bounce is recorded but doesn’t.
• email.complained — the recipient marked it as spam. This suppresses the address too.

A message that exhausts its retries or hits a permanent provider error ends in the failed state — visible on the message, but note there is no email.failed event.

Stay inside your quota

Every Org has a daily send quota — the number of messages it can have accepted in a day. New Orgs start small and the ceiling rises automatically as you build a clean sending history; staff can also raise it on request. The current quota and how much you’ve used today are on the Sending page and in lbr email settings.

Two structural controls keep shared sending reputation healthy, and neither involves anyone reading your mail:

• Auto-pause. If your trailing bounce rate crosses ~5%, or your complaint rate crosses ~0.1%, sending for the Org pauses automatically. Unpausing is a manual staff action once the cause is understood.
• The quota itself, charged atomically at accept, caps the blast radius of a misbehaving sender.

See Quotas & limits for the exact numbers and message caps.

Where to next

• Send keys — create, scope, and rotate the credential.
• Webhooks — receive delivery events as signed HTTP callbacks.
• Suppression — how bounces and complaints stop future sends.
• Quotas & limits — the send quota, message size, and retention.