Skip to content

Elastic Email

Elastic Email delivery via HTTP API. Registers an email delivery strategy named elastic_email with the notification module's strategy pool, sending transactional email through Elastic Email's v2 POST /email/send endpoint over httpx. Choose it when you want API-key-based email delivery through an Elastic Email account rather than SMTP or AWS.

At a glance
Extension id elastic_email
Category communication
Version 0.0.1
Provides Email delivery strategy (elastic_email)
External account Elastic Email — API key (required)

What It Provides

  • Email delivery strategy — ElasticEmailStrategy (ext_elastic_email/strategy.py), an implementation of the core EmailDeliveryStrategy interface, registered as elastic_email via register_email_strategy("elastic_email", ElasticEmailStrategy) on activation. Registration is claimed in the registration ledger — see Email delivery in Building Extensions.
  • Each send posts a form-encoded request to {api_url}/email/send carrying apikey, from, fromName, to, subject, bodyHtml, and bodyText, with a 60-second HTTP timeout.
  • Nothing else — no webhook endpoints, Temporal workflows, schedules, admin pages, GraphQL fields, or event subscriptions.

Setup

  1. Once installed (or dev-linked in development), the extension is discovered at startup. It uses httpx, which is a core dependency — no extra install is needed.
  2. Enable the extension for a channel from Settings > Extensions (per-channel activation via ChannelExtension).
  3. Make it the active email provider on Settings > Email: the page lists Elastic Email as a provider option (it checks that the elastic_email extension is installed) with fields for the API key and API URL alongside the default from address/name. Saving writes the email_provider platform setting that the notification service reads at send time.

Configuration Reference

Key Type Required Secret Description
api_key string Yes Yes —
default_from_email string No No Defaults to empty
default_from_name string No No Defaults to Vectis Commerce
api_url string No No Defaults to https://api.elasticemail.com/v2

Note

This schema drives the generic Configure form on Settings > Extensions. The credentials actually used at send time come from the email_provider platform setting (managed on Settings > Email) — the notification service does not read the per-channel extension config when building the strategy.

Operational Notes

  • Send-time construction. The notification service builds the strategy from the email_provider setting on every send: the setting's keys (minus provider) are passed as constructor arguments — api_key, default_from, default_from_name, and optional api_url. If the setting is missing, names an unknown provider, or construction fails, delivery silently falls back to the console (dev logging) strategy and the failure is logged server-side.
  • Response handling. The strategy parses Elastic Email's JSON envelope: on success: true the data value is recorded as the message id; on success: false the API's error string is surfaced. A non-JSON 2xx response still counts as sent (without a message id); any other HTTP status is reported as HTTP <status> with the response body.
  • Custom API URL. The api_url value is configurable (trailing slashes are stripped), so a proxy or regional endpoint can be substituted for the default v2 API base.
  • Batch sends are sequential. send_batch loops over single POST /email/send calls.
  • Every templated send is recorded in notification_logs with the provider name and message id.
  • Alternative email providers: built-in SMTP and console strategies ship with core; Amazon SES is available as another extension.