Transactional and marketing

Most businesses send two kinds of email and buy them from two companies. One vendor sends the receipts and the password resets, another sends the newsletter, and nobody planned it that way: it happened because every vendor picks a side. The transactional products treat campaigns as an afterthought, the marketing products sell transactional sending as a separate purchase, and you end up with both.

SendHeron runs both streams. Transactional mail goes out through a single endpoint, immediately or at a scheduled time, and accepts an idempotency key so a retry after a timeout cannot send the same receipt twice. Templates carry Handlebars or Liquid variables, and passing a contact id fills that contact's fields in for you. Campaigns go to a list or a segment. Multi-step sequences run delays and conditions, started by a tag or by a custom event you post from your own backend.

The two streams are reported separately, because blending them hides the thing you need to see. A complaint spike on a campaign is invisible inside a combined number until it has already damaged the reputation that carries your password resets.

Classification comes from two inputs and the stricter one wins. A template declares its type, and the channel it goes out on sets a floor: a campaign or a bulk send is always marketing, a send through the transactional endpoint is always transactional, and a sequence step follows its template. The floor only ever tightens. Tagging a template transactional and then mailing it as a campaign produces a marketing message, with the unsubscribe link attached, because the alternative would make that flag a switch for stripping unsubscribe links off a mass mailing.

What the classification changes is concrete. Marketing mail gets an unsubscribe link and the List-Unsubscribe headers for RFC 8058 one-click opt-out, and it honours opt-outs. Transactional mail gets neither and ignores them, which is why a customer who left your newsletter can still reset their password.

Suppression has two tiers, and the split is the whole design. A hard suppression, meaning a bounce or a spam complaint, blocks every message including transactional, across your whole organization, with no override: continuing to mail an address that hard bounced is what gets a sending domain blocklisted, so it is a deliverability fact rather than a preference. A consent suppression, meaning an unsubscribe, blocks marketing only, and stays inside the one workspace whose brand the recipient actually left. If you run two brands in two workspaces, somebody leaving the first still hears from the second. If an address carries both kinds, the stricter one decides.

# One call per contact. No importer, this is the path.
curl -X PUT https://api.sendheron.com/api/v1/contacts \
  -H "Authorization: Bearer $SENDHERON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "[email protected]",
       "firstName": "Ada",
       "source": "import"}'

# Matched on email, so re-running a failed batch
# updates Ada rather than creating a second Ada.

• Transactional sends, immediate or scheduled, with an idempotency key
• Handlebars or Liquid variables, and contact fields filled in automatically
• Campaigns to a static list or a rule-driven segment
• Multi-step sequences with delays and conditions, started by a tag or an event
• One-click unsubscribe headers on marketing mail, per RFC 8058
• Domain authentication, so mail leaves from your own domain
• Delivery and engagement analytics for both streams, reported separately

See the sending endpoints

The part a two-vendor setup cannot fix is that the two vendors do not share a suppression list. Somebody unsubscribes in the marketing tool and the transactional tool has never heard of it. Somebody hard bounces in the transactional tool and the next campaign mails the dead address anyway, on a domain reputation both of them are drawing down. You can sync the lists yourself, and the sync is either late or wrong on the day it matters. Here there is one list, checked by both streams, split by the rule that actually matters rather than by which product wrote the row.

What is missing is worth knowing before you plan a migration. There is no import wizard. Moving your contacts across means calling the upsert endpoint, which matches on email address, from a script or a sync job: that is a perfectly good migration path and it is idempotent, so a re-run after a failed batch updates people instead of duplicating them, but it is a script you write rather than a file you drag in.

Sequences cannot be built over the API either. Creating one, editing its steps and wiring them together is dashboard work. The API reads sequences, enrols contacts, and pauses or resumes them, which covers driving an automation you already designed but not designing it. Attachments are not supported and the field is rejected rather than silently ignored. There are also no outbound event webhooks yet, so if you are arriving from a vendor where you subscribed to delivered and bounced events, there is nowhere to point that today: the analytics endpoints and the per-contact timeline are what exist instead.