Features

PayloadCMS useSend Email Adapter routes email delivery through the useSend REST API rather than SMTP. Email is dispatched via stateless HTTP requests, eliminating persistent connections and aligning with serverless and short-lived runtime models. These capabilities make the adapter well suited to modern application architectures that prioritise scalability, portability, and operational simplicity.

REST API

The adapter integrates with PayloadCMS using the standard email configuration within buildConfig. Existing calls to payload.sendEmail() continue to operate without modification, ensuring seamless adoption and minimal migration effort.

// payload.config.ts
  email: sendAdapter({
    apiKey: process.env.USESEND_API_KEY!,
    useSendUrl: process.env.USESEND_URL!,
    defaultFromName: 'Example',
    defaultFromAddress: 'no-reply@example.com',
  })

By delegating SMTP to a REST service, the adapter removes the need for long‑lived connections and fits naturally into stateless environments like Vercel or AWS Lambda.

REST-based delivery removes the need to manage SMTP connection lifecycles, authentication state, or provider-specific transport behaviour. Each email send is a discrete HTTP request, resulting in predictable execution, reduced operational complexity, and consistent behaviour across runtime environments.

Templates

Template-based email delivery is supported through useSend. Emails may reference a templateId, with dynamic variables supplied at send time for server-side rendering. Template storage, rendering, and versioning are handled entirely by useSend rather than Payload.

Dynamic variables (see Variables) are passed as a key‑value object and rendered into the template at send time. This enables provider-native templating while keeping presentation logic out of application code. Email designs are defined once in useSend and reused across Payload-driven workflows.

Templates are best suited for repeatable communication patterns such as onboarding emails, password resets, and system notifications. This approach centralises email design, simplifies maintenance, and allows content changes without requiring application redeployment.

Variables

Variables map directly to your template syntax (for example, {{firstName}}), and are provided as a typed object from your Payload code. This enables consistent, provider-native templating without embedding template logic in the application.

Scheduling

The adapter supports scheduled email delivery using an ISO 8601 timestamp. When a scheduled time is provided, messages are queued and dispatched by useSend at the specified moment, without requiring background jobs or task schedulers within the Payload runtime.

This capability is particularly useful for reminder workflows, batch notifications, and time-zone-aware delivery, while keeping application logic focused on core responsibilities.

Observability

Delivery status, engagement metrics, and suppression handling are managed by useSend. You can keep observability inside useSend, or optionally sync key events back into Payload via webhooks if your project requires in‑app status tracking. Logs and analytics are exposed through the useSend interface, with no additional logging configuration required in Payload.

Teams gain visibility into bounces, opens, clicks, and unsubscribe events directly through the useSend dashboard, enabling monitoring and optimisation without additional instrumentation.

Deployment

A single adapter configuration supports both managed cloud and self-hosted useSend deployments. The only environment-specific change is the API base URL, allowing delivery infrastructure to evolve independently of application code.

This flexibility enables teams to begin with useSend Cloud and later migrate to self-hosted infrastructure to meet regulatory, privacy, or data residency requirements, without altering Payload email logic.