Use an existing email integration

A shared email request can be translated by several named provider adapters.

Use an existing email integration

Wildo’s provider registry publishes modules for established email providers, so installing and selecting one does not require rebuilding message formatting, authentication and response handling.

Resend ships with the engine. Postmark, SendGrid, Mailgun, Brevo and Mailchimp are registry packages an application installs with wildo registry add wildo/providers/<vendor>. Each module translates the shared email request into the provider’s own contract.

Example — Move delivery to Brevo

Keep the account templates and operation notifications, install Brevo from the registry, then configure it as the transactional provider with its deployment credential.

For engineers

Make Brevo available and select it

Install the package first: wildo registry add wildo/providers/brevo, from the application root. Then select it. Application example adapted from the existing backend-scope pattern and Brevo’s module contract. Merge this email section into wildo.saas.config.ts; keep the application’s other capabilities and providers.

import { EngineCapability } from '@wildo-ai/saas-models';
import { defineSaaSProviders } from '@wildo-ai/platform-config-lib';

const emailProviders = defineSaaSProviders({
  scopes: {
    backend: {
      providers: {
        brevo: {
          engineCapabilities: [EngineCapability.EMAIL_TRANSACTIONAL],
          providerCapabilities: ['EMAIL_TRANSACTIONAL'],
          protocols: ['EMAIL_PROVIDER'],
        },
      },
      selection: {
        [EngineCapability.EMAIL_TRANSACTIONAL]: { primary: 'brevo' },
      },
    },
  },
});

Assign emailProviders to the existing config’s providers property and enable EMAIL_TRANSACTIONAL in its engineCapabilities. In backend configuration, set email.from. Put BREVO_API_KEY in the target environment’s secret providerEnv, not in this provider declaration. Regenerate with wildo config sync --env <environment> from the app root, then inspect the backend provider runtime and emitted environment.

Supply the inputs the adapter actually reads

These are the provider modules’ current configuration contracts (Resend’s in the engine, the others’ in their registry packages), not a comparison of vendor plans.

Provider reference	Credential environment key	Setup detail that matters
`resend`	`RESEND_API_KEY`	Transactional provider selection and a valid sender
`postmark`	`POSTMARK_SERVER_TOKEN`	Uses a server token, not an account-management token
`sendgrid`	`SENDGRID_API_KEY`	Transactional and marketing selections are separate
`mailgun`	`MAILGUN_API_KEY`	Also requires the sending domain for its `/{domain}/messages` endpoint
`brevo`	`BREVO_API_KEY`	The adapter supplies the API-key authentication header
`mailchimp`	`MANDRILL_API_KEY`	Transactional delivery uses Mandrill’s credential identity

For Mailgun, the email resolver reads the selected provider configuration’s domain, or MAILGUN_DOMAIN from its environment. This must be the sending domain, not merely the application’s website host. It refuses to send when the required endpoint domain is absent.

Verify the handoff, not just the configuration

Use a registered template and inspect EmailSendResult: outcome, submission identity and provider receipts. The normal sender uses the same template/context API across providers, while each module supplies encoding, authentication and result classification. Attachment ceilings and idempotency support can differ; changing a provider does not erase those differences.

An accepted submission confirms the provider handoff. It does not establish inbox placement. Marketing capability support is a separate routing decision, not campaign orchestration.

Use an existing email integration