How to Connect Sendy, AWS SES and Next.js for Newsletter Subscriptions

Sendy can be used as a self-hosted newsletter platform, Amazon SES can handle email delivery, and Next.js can provide the website subscription experience. WordPress can remain the content-management system while Sendy manages subscriber lists and campaigns separately.

The main challenge is not sending one email. It is connecting the systems securely, keeping API credentials on the server, processing background jobs reliably, and making the subscription experience work well for real visitors.

This guide focuses on the architecture and the important implementation details without assuming that Sendy, AWS SES, or Next.js is automatically the right choice for every business.

What Does Each Part of the Stack Do?

The setup is easier to understand when each system has a clear responsibility.

Visitor
   ↓
Next.js website
   ↓
Secure server-side subscription request
   ↓
Sendy
   ↓
Amazon SES
   ↓
Subscriber inbox

If WordPress is also part of the website, it can continue to manage content independently.

Next.js

The public website and subscription interface.

Sendy

The newsletter application that manages subscribers, lists, campaigns and related email-marketing workflows.

Amazon SES

The delivery service that sends the email.

WordPress

An optional CMS that can continue to manage the website's content.

Keeping these responsibilities separate makes the architecture easier to reason about and maintain.

Is Sendy Right for Your Business?

Sendy can make sense when you want:

• A self-hosted newsletter platform
• Direct integration with Amazon SES
• More control over your newsletter environment
• A subscription system that can be connected to a custom website
• A setup that your team is comfortable maintaining

A managed email platform may be more appropriate when you want:

• Minimal infrastructure maintenance
• A fully managed SaaS product
• Built-in automation and marketing features
• Less technical involvement from the team
• A simpler operational model

There is no universal winner.

The best choice depends on how your marketing team works, how much infrastructure you want to manage, and what integrations the website needs.

Newsletter Email vs Transactional Email

This distinction is important because the architecture and CorgenX articles around AWS SES serve different purposes.

Newsletter and marketing email

Sendy is useful for workflows such as:

• Subscriber lists
• Campaigns
• Newsletter broadcasts
• Unsubscribes
• Subscriber management
• Email-marketing automation supported by the platform

Transactional email

A web application may separately need messages such as:

• Contact-form notifications
• Account confirmations
• Password-related emails
• Application events
• Order or enquiry notifications

Those can be implemented directly through the application's email infrastructure.

For a Next.js + AWS SES transactional-email architecture, see our Next.js and AWS SES email guide.

The important point is:

Sendy is primarily the newsletter/campaign layer. It does not have to become the sending architecture for every email your website ever sends.

Before You Start

You will typically need:

• A domain you control
• DNS access
• An AWS account
• A verified sending identity in Amazon SES
• Appropriate SES sending access for your use case
• A server supported by the Sendy version you are installing
• A Sendy license
• A Next.js application if you want a custom subscription experience

Check the current Sendy and AWS requirements before deployment because supported software versions and hosting requirements can change.

Part 1: Set Up Sendy

Use a Dedicated Location

A clean subdomain such as:

newsletter.example.com

can keep the newsletter application separate from the public website.

This makes the architecture easier to manage and avoids mixing the Sendy application files with a WordPress installation.

Configure the Application

Your Sendy installation needs its application URL and database connection configured correctly.

A simplified configuration may look like:

$app_path = 'https://newsletter.example.com';
$dbHost   = 'localhost';
$dbUser   = 'your_db_user';
$dbPass   = 'your_db_password';
$dbName   = 'your_db_name';

Use the exact configuration format required by the Sendy version you are installing.

Protect Configuration Secrets

Database credentials, API credentials and other secrets should never be exposed to the browser or committed to a public repository.

After installation, also follow the current Sendy security and deployment guidance for removing installation files and locking down the application.

Part 2: Connect Amazon SES

Sendy uses Amazon SES as its email-delivery layer in this architecture.

The exact AWS setup depends on your current SES account and region, but the important steps are:

Verify the sending domain

Add the DNS records Amazon SES provides for domain verification and DKIM.

Review sending access

New SES accounts may begin with restrictions. Production sending capabilities and quotas depend on your AWS account and use case.

Configure permissions carefully

Use credentials with only the permissions required for the Sendy workflow.

Do not use a broad administrative AWS credential when a narrower permission set will work.

Keep the region consistent

Choose an SES region that fits your architecture, operational requirements and compliance needs.

Do not assume that one region is universally best for every business.

For current AWS pricing and quotas, use the official AWS documentation because these details can change.

Part 3: Connect the Next.js Subscription Form

The public form should never send the Sendy API key directly from the browser.

Instead:

Browser
   ↓
Next.js server-side action or route
   ↓
Sendy API

That keeps the credential on the server.

Server-side subscription example

A simplified Server Action can look like this:

"use server";

export async function subscribeUser(formData: FormData) {
  const email = formData.get("email");
  const name = formData.get("name") || "";

  if (typeof email !== "string" || !email.trim()) {
    return {
      success: false,
      message: "Email is required.",
    };
  }

  const params = new URLSearchParams({
    api_key: process.env.SENDY_API_KEY || "",
    list: process.env.SENDY_LIST_ID || "",
    email: email.trim(),
    name: typeof name === "string" ? name : "",
    boolean: "true",
  });

  try {
    const response = await fetch(
      `${process.env.SENDY_URL}/subscribe`,
      {
        method: "POST",
        headers: {
          "Content-Type": "application/x-www-form-urlencoded",
        },
        body: params.toString(),
        signal: AbortSignal.timeout(5000),
      }
    );

    const text = await response.text();

    if (text === "1") {
      return {
        success: true,
        message: "Subscribed successfully.",
      };
    }

    return {
      success: false,
      message: text,
    };
  } catch (error) {
    console.error("Sendy subscription error:", error);

    return {
      success: false,
      message: "Unable to subscribe right now. Please try again.",
    };
  }
}

The example demonstrates the important architecture:

The browser never receives SENDY_API_KEY.

Environment variables

Keep credentials server-side:

SENDY_URL=https://newsletter.example.com
SENDY_API_KEY=your_server_side_key
SENDY_LIST_ID=your_list_id

Do not use a NEXT_PUBLIC_ prefix for secrets.

Protect the Subscription Endpoint

A public newsletter form can attract automated submissions, so API security should be part of the implementation.

At minimum:

Validate input on the server

Check:

• Email format
• Field length
• Unexpected or malformed input
• Request size

Add rate limiting

A single source should not be able to submit hundreds or thousands of requests in a short period.

Consider bot protection

Depending on the level of spam, you may use:

• Honeypot fields
• CAPTCHA or managed challenges
• Behavioral checks
• Rate limiting
• Abuse monitoring

Do not expose Sendy credentials

The browser should only interact with your public form endpoint.

What Should the Frontend Form Do?

The visible form can remain simple:

<form action={subscribeUser}>
  <input
    type="email"
    name="email"
    placeholder="you@example.com"
    required
  />

  <button type="submit">
    Subscribe
  </button>
</form>

The frontend should also handle:

• Loading state
• Success message
• Error message
• Accessible labels
• Keyboard interaction
• Mobile layout

The technical integration should not make the form unnecessarily complicated for the visitor.

Understanding Sendy Responses

Sendy can return different responses depending on the request and configuration.

Examples may include:

Treat the exact response values as part of the Sendy version/API you are integrating with and verify them against the current Sendy documentation before building business logic around them.

Part 4: WordPress Integration

If WordPress is the public website, there are two common approaches.

Option 1: Use Sendy's hosted subscription form

This is the simpler path.

It can be appropriate when you want:

• Minimal custom development
• A straightforward newsletter form
• Sendy to control the subscription experience

Option 2: Build a custom website form

The website can send the subscription request through a server-side integration.

This gives you more control over:

• Design
• Validation
• User experience
• Analytics
• Error handling
• Integration with other website workflows

If Next.js is already the public frontend, there is usually little reason to route a newsletter subscription through WordPress unless WordPress needs to participate in that workflow.

Part 5: Background Jobs and Cron

Sendy uses background jobs for tasks such as scheduled sending and other processing.

The exact jobs and recommended frequency depend on the Sendy version and enabled features.

Typical tasks can include:

• Scheduled campaigns
• Autoresponders
• Subscriber imports
• Segment updates

Your deployment checklist should therefore include:

Confirm every background task required by your Sendy version is configured and running successfully.

Do not assume that a campaign is broken just because the web interface looks correct. A failed background job can stop scheduled processing.

Example cron pattern

A command may look like:

*/5 * * * * php /path/to/sendy/scheduled.php > /dev/null 2>&1

But use the exact scripts and intervals documented for the Sendy version and workflows you are running.

How to Verify Cron Is Working

Test the actual workflow:

1. Create a test subscriber.
2. Confirm the subscriber appears in Sendy.
3. Schedule a small test campaign.
4. Confirm the background process runs.
5. Verify the email is delivered.
6. Review Sendy and server logs for errors.

This is more reliable than simply assuming the cron process is configured correctly.

Common Setup Problems

Avoid copying old server-specific fixes without checking the current Sendy and hosting documentation first. Hosting platforms, PHP versions and server configurations change.

Common Security Mistakes

Exposing the Sendy API key

Never place the key in client-side JavaScript.

Using broad AWS permissions

Give the integration only the permissions it needs.

Leaving installation files exposed

Complete the installation and follow Sendy's current post-installation security steps.

Skipping rate limiting

A publicly accessible subscription endpoint should be treated like any other public API.

Trusting client-side validation

Validate the request again on the server.

What About Hosting and the Database?

The application, database and email-delivery layers all affect reliability.

Your hosting choice should consider:

• Sendy's current system requirements
• PHP support
• Database support
• Server performance
• Backup strategy
• Security updates
• Monitoring
• Cron support
• Network connectivity

Keeping the database close to the application can reduce network overhead, but the correct architecture depends on the workload and the hosting options supported by your Sendy version.

Do not treat one server layout as a universal rule.

How This Differs From Transactional Email

This is worth repeating because the two architectures are easy to mix up.

Newsletter flow

Website
   ↓
Sendy
   ↓
Amazon SES
   ↓
Newsletter subscriber

Transactional application email

Website / Application
   ↓
Server-side email service
   ↓
Amazon SES
   ↓
Recipient

You can use the same SES account or related infrastructure where appropriate, but the application responsibilities are different.

Newsletter software needs:

• List management
• Campaign management
• Unsubscribe handling
• Subscriber workflows

Transactional email needs:

• Application events
• Reliable delivery
• User-specific messages
• Error handling
• Application integration

Keeping these responsibilities clear makes the system easier to maintain.

Sendy Maintenance: What Should You Plan For?

Self-hosted software gives you control, but it also gives you responsibilities.

Plan for:

• Sendy updates
• PHP compatibility
• Database backups
• Server security
• Credential rotation
• Cron monitoring
• SES reputation monitoring
• Bounce and complaint handling
• Unsubscribe compliance
• Application logs
• Recovery procedures

This is the main operational trade-off compared with a fully managed newsletter platform.

When a Managed Newsletter Platform May Be Better

Sendy is not automatically the right answer simply because it can be inexpensive.

A managed platform may be a better fit when:

• Marketing users want minimal technical maintenance.
• The organization needs advanced built-in automation.
• The team does not want to operate PHP/MySQL infrastructure.
• You want vendor-managed updates and support.

Choose the platform around the team's actual workflow.

How CorgenX Looks at This Architecture

At CorgenX, we see Sendy + SES + Next.js as one possible integration pattern rather than a universal stack.

The important part is separating responsibilities:

Website

→ collects the subscriber request

Server-side integration

→ protects credentials and validates the request

Sendy

→ manages newsletter subscribers and campaigns

SES

→ handles email delivery

That separation makes it easier to change one component later without redesigning the entire website.

For broader website/API integration work, see our Web Development Services.

For application-heavy workflows, Custom Web Applications may be a better fit.

FAQs

What is Sendy used for?

Sendy is a self-hosted email-marketing application used for subscriber lists, campaigns and related newsletter workflows. In this architecture, Amazon SES handles message delivery.

Why connect Sendy to Next.js?

Next.js can provide a custom subscription experience while keeping the Sendy API key on the server. This gives you control over the website form, validation, user experience and integration with the rest of the application.

Should the Sendy API key be used in client-side code?

No. Keep it on the server. The browser should call your own server-side endpoint or action, which then communicates with Sendy.

Can I use Sendy with WordPress?

Yes. You can use Sendy's form directly or connect a custom WordPress form to Sendy's API through a server-side integration. If Next.js is already the public frontend, you can usually keep the subscription flow in the Next.js layer.

Do I need Amazon SES to use Sendy?

Sendy's deployment and delivery configuration should be checked against the current Sendy documentation. This guide assumes the common architecture where Sendy uses Amazon SES for email delivery.

Is Sendy better than a managed email platform?

Not automatically. Sendy can be attractive if you want control and are comfortable maintaining the infrastructure. A managed platform may be better if the team prioritizes simplicity and vendor-managed operations.

How do I prevent newsletter signup spam?

Use server-side validation, rate limiting, and appropriate bot controls. Keep the Sendy API key private and monitor suspicious submission patterns.

Is this the same as sending transactional email from Next.js?

No. Newsletter management and transactional application email solve different problems. Sendy is focused on subscriber and campaign management; transactional email is usually triggered directly by application events.

Final Takeaway

Sendy, Amazon SES and Next.js can work well together when each part has a clear responsibility:

Next.js

→ website experience

Server-side integration

→ secure subscription flow

Sendy

→ newsletter management

Amazon SES

→ email delivery

The architecture is useful when you want control and are comfortable maintaining the systems involved.

If your business wants a simpler managed newsletter platform, another solution may be more appropriate.

As with any web architecture, the best choice is not the one with the most technology.

Choose the smallest reliable setup that solves the actual business problem.