Resources · Developer Center

Email Delivery Providers

Send through the email providers you already run. An admin configures one or more providers and an ordered fallback in the back office; Flash sends through them as a waterfall that always ends at the platform's managed email service. The provider is a transport swap only — Flash still injects tracking, personalization, A/B branches and unsubscribe handling itself, so nothing changes about how a campaign is built or measured.

Book a demo Browse the API

What you can connect

Configured under Settings → Email Providers by an org admin — never per-campaign by a marketer.

SendGrid

Connect your SendGrid account with an API key. Flash sends via the v3 mail API.

Amazon SES (your account)

Bring your own AWS SES account (access key / region / verified from). Distinct from the platform's fallback SES.

Custom REST — any ESP

Point Flash at any provider's JSON send API with a field map. No adapter to wait on.

Raw SMTP relay is on the roadmap, not yet available — connect via a provider's API for now.

The fallback waterfall

Each send tries your providers in the priority order you set; a failing or unavailable provider is skipped and delivery falls to the next. The platform's managed email service is always the terminal fallback.

// Providers are tried in the priority order an admin sets. The list ALWAYS ends at
// the platform's managed Amazon SES account (the terminal fallback), which uses its
// own verified from-address so a fallback never bounces on an unverified domain.
Priority 1  →  SendGrid            (your account)
Priority 2  →  Amazon SES          (your own AWS account)
Priority 3  →  Custom REST         (any ESP with a send API)
Terminal    →  Platform Amazon SES (always on — the safety net)
// A provider that errors or is circuit-broken is skipped; delivery falls to the next.

Connect any ESP with Custom REST

If your provider isn't built in, connect it by its send API — supply the endpoint, the auth header, and a field map. No code, no adapter to build.

// A "Custom REST" provider connects ANY ESP that exposes a JSON send API — no
// code, just configuration. An admin supplies the endpoint, the auth header, and a
// field map; Flash builds the request per message. Example (a generic ESP):
{
  "provider": "custom_rest",
  "config": {
    "endpoint":    "https://api.your-esp.com/v1/send",
    "authHeader":  "Authorization",
    "authScheme":  "Bearer",              // → "Authorization: Bearer <apiKey>"
    "toField":     "to",
    "fromField":   "from",
    "subjectField":"subject",
    "htmlField":   "html"
  },
  "secret": { "apiKey": "sk_live_…" }      // encrypted at rest; never returned
}
// Per send, Flash POSTs: { "to": "...", "from": "...", "subject": "...", "html": "..." }
// with the auth header applied. 401/403 → credentials error (skip to next provider),
// 5xx/timeout → transient (skip to next provider). The HTML already carries Flash's
// own tracking pixel + link redirects, so opens/clicks keep working.

Sync unsubscribes back into Flash

When you send through your own providers, opt-outs may be captured outside Flash — by your ESP, your preference center, or a form. Push them back with the Unsubscribe API so Flash suppresses that address on every send. You can also read an address's opt-out status. Authenticate with a tenant API key; the email is the identity.

// Push an opt-out INTO Flash — from your ESP's unsubscribe webhook, your own
// preference center, or a third-party form. Flash then suppresses this address on
// EVERY campaign send (the same signal the audience resolver checks). Idempotent.
POST https://flash.socialhub.ai/api/v2/members/unsubscribe
Authorization: Bearer fl_live_…            // scope: members:write
Content-Type: application/json
{ "email": "ada@acme.com" }
// → 200  { "data": { "email": "ada@acme.com", "unsubscribed": true } }

// Read an address's opt-out status (e.g. reconcile before a bulk send):
GET https://flash.socialhub.ai/api/v2/members/unsubscribe?email=ada@acme.com
Authorization: Bearer fl_live_…            // scope: members:read
// → 200  { "data": { "email": "ada@acme.com", "unsubscribed": true } }

// Re-subscribing is deliberately NOT an API toggle — re-granting marketing consent
// needs provable opt-in (CAN-SPAM / CASL), so it goes through the member's own
// consent flow, never this endpoint.

How credentials are kept safe

Encrypted at rest

Every provider secret is encrypted immediately (AES-256-GCM) and never returned by the API or shown again — write-only in the UI.

Admin-only

Only org owners / admins can add, reorder, test or remove providers. Marketers never see or choose a provider.

Transport-only

Providers carry the message; Flash still owns tracking, personalization, A/B, unsubscribe headers and frequency caps — swap a provider without changing any of it.

Safe by default

If a provider's config can't be read, or every provider fails, delivery falls back to the platform's managed email service — sending never stalls.

See also: Cross-channel delivery · REST API

Bringing your own email provider?

Talk to an engineer about your ESP, deliverability, fallback strategy, or connecting a provider by its API.

Talk to engineering