`. The link text should describe the destination — "Read the case study" not "Click here."
```html
Read the case study
Click here
```
**Buttons need 44×44px minimum touch target.** WCAG 2.5.5 (Target Size). Mobile readers with motor impairments or in non-ideal conditions (gloves, jolting transit) need at least 44px square to tap reliably. Most email CTAs need padding to hit this — `padding: 16px 32px` gets you there with normal text.
**Color is a secondary signal.** Underline links by default (don't disable underlines on `
` in email body text — most clients show them by default). For buttons, the button shape + bold weight + label clarity all carry meaning beyond color, so a color-blind user still knows it's actionable.
For Outlook-specific button rendering (the hardest client), see [Bulletproof CTA Buttons for Outlook](https://acellesend.com/kb/articles/bulletproof-cta-buttons-for-outlook).
## Inline-style techniques that email clients allow
CSS-in-`
```
The `@media` query flips `td` elements to `display: block` on mobile, which makes them stack.
### 2. 16px minimum body font
**Why:** smaller than 16px on a 4-inch screen is genuinely hard to read. Apple's iOS design guidelines specifically recommend 16px as the minimum for sustained reading; Google's Material Design says 14-16px minimum. Below that, recipients zoom in (causing horizontal-scroll layout damage) or just close the email.
```html
```
In an `@media (max-width: 600px)` block, bump body to 18px if you want even more headroom:
```css
@media only screen and (max-width: 600px) {
.mobile-body { font-size: 18px !important; }
}
```
**Don't go below 14px** for legal disclaimers / unsubscribe footers — even if visually they "look like fine print", the actual fine print becomes invisible on mobile.
### 3. 44×44 px minimum tap targets
**Why:** Apple's Human Interface Guidelines specify 44×44 pt as the minimum tap target size — anything smaller produces frustrating mis-taps. Google's Material Design uses 48dp (similar). Tappable elements smaller than that fail accessibility checks too.
For buttons + CTA links:
```html
```
The combination of `padding: 16px 32px` + `font-size: 16px` typically produces a button ~52px tall × at-least-44px wide = comfortably tappable.
For inline text links (e.g., "Learn more →"), wrap them with spacing:
```html
Read more about our pricing and how we compare.
```
### 4. 600px max width with responsive scaling
**Why:** 600px is the de-facto email standard. Wider tables either crop in Outlook desktop or trigger horizontal scroll in Gmail web. On mobile, the 600px table should scale to full width.
```html
```
### 5. Finger-friendly padding (20px+ on mobile)
**Why:** content butted against the screen edges feels claustrophobic on mobile. 20-30px padding on all sides gives reading comfort.
```html
Content
|
```
Don't let mobile padding drop below 16px — content needs breathing room.
### 6. Full-width images that scale
**Why:** an image fixed at `width="600"` will overflow a 360px-wide mobile screen, causing horizontal scroll. Make images responsive:
```html
```
- `width="600"` (attribute, not style) — for Outlook desktop, which doesn't fully respect CSS width
- `width: 100%; max-width: 600px;` (style) — scales down on mobile, caps at 600px on desktop
- `height: auto;` — preserves aspect ratio
- `display: block;` — removes the 4px bottom gap browsers add to inline images
For decorative icons (small images): use fixed `width="40" height="40" style="width: 40px; height: 40px;"` — don't scale.
## Worked example — mobile-first responsive template
```html
|
|
Hi {FIRST_NAME}
Body content with comfortable 16px font, 1.5 line-height.
|
|
|
|
```
## Testing protocol
1. **Send a test to yourself** on at least: iPhone (Apple Mail), Android (Gmail app), iPad (Apple Mail), and one desktop browser (Gmail web)
2. **Resize browser windows** — open the email on desktop Gmail, then resize the window from 600px down to 320px while watching how it adapts
3. **Use Litmus / Email on Acid** for cross-client at-scale verification
4. **Check tap-target sizes** physically — tap each link/button with your thumb on the actual mobile device, not just visual inspection
The "send to your own phone" test catches 80% of mobile issues. Spend the 5 minutes.
## Common failures
| What you see | Likely cause | Fix |
|---|---|---|
| Horizontal scroll on mobile | Image or table wider than screen | Use `width: 100%; max-width: 600px;` on images; use `mobile-fluid` class on outer table |
| Text too small to read on mobile | Body < 16px | Bump to 16px; or 18px on mobile via `@media` |
| Mis-taps on CTAs | Buttons < 44×44px | Increase padding + line-height per Principle 3 |
| Tested desktop, mobile broken | Designed desktop-first | Re-design starting from mobile constraints |
| Hero image cropped on mobile | Fixed-width attribute without `max-width: 100%` style | Add both width attribute (Outlook) AND CSS width style (everyone else) |
| Stacked columns don't stack | `display: block` not in `@media` query | Verify the `@media (max-width: 600px)` block exists + `!important` on the property |
| Padding looks tight on small phones | Mobile-only padding > screen width minus content | Use 20-24px mobile padding, never less than 16px |
## FAQ
**Can I just use AcelleMail's drag-and-drop builder?** Yes — recent versions generate responsive mobile-friendly HTML automatically. Use the raw HTML editor only when you need precise control (e.g., porting an externally-designed template).
**My audience is 90% desktop B2B. Do I still need mobile-first?** Less urgent — but mobile share is rising in B2B too. Mobile-first design also forces clearer hierarchy, which benefits desktop. Worth doing even at low mobile percentages.
**What about email-on-watch (Apple Watch)?** Mostly text-only rendering; recipients almost never act on watch — they triage and read in detail later on phone. Don't optimize for watch specifically.
**Tablet design — separate breakpoint?** Most tablets (iPad, Galaxy Tab) render emails at desktop sizes. Don't add a tablet-specific breakpoint; design for mobile + desktop and tablets handle themselves.
**AMP for Email mobile?** Gmail supports AMP for Email; the responsive primitives are stronger. Niche; not bundled with AcelleMail.
## Related articles
- [Email Template Design Best Practices](https://acellesend.com/kb/articles/email-template-design-best-practices) — umbrella design rules
- [Dark Mode Email Design](https://acellesend.com/kb/articles/dark-mode-email-design) — most mobile reading happens in dark mode
- [Understanding Email Client Rendering Differences](https://acellesend.com/kb/articles/understanding-email-client-rendering-differences) — full per-client rendering guide
- [Email Preheader Text](https://acellesend.com/kb/articles/email-preheader-text-the-hidden-conversion-booster) — preheader is most-visible on mobile
- [Click Map Analysis](https://acellesend.com/kb/articles/click-map-analysis-optimize-your-email-layout) — measure tap behavior to validate mobile design
- [Personalization Beyond First Name](https://acellesend.com/kb/articles/personalization-beyond-first-name-advanced-merge-tags) — merge tags + mobile rendering
---
# Webhook Events Reference
> AcelleMail has three distinct webhook systems — customer-lifecycle webhooks (SaaS billing events), per-campaign webhooks (open/click/bounce on a specific campaign), and inbound webhooks from sending providers (SES SNS, Mailgun events). This reference documents each, with the real event names from the Acelle source — not the made-up ones some older guides list.
- Canonical URL: https://acellesend.com/kb/articles/webhook-events-reference
- Author: Tom Becker, Developer Editor
- Category: Developer Guide — REST API, webhooks, customization, extending source code, plugins
- Content type: reference · Difficulty: intermediate
- Tags: Acellemail
- Published: 2026-04-17 · Last updated: 2026-08-15
- Reading time: 9 min
- Publisher: AcelleMail Knowledge Base, https://acellesend.com/kb
---
## What this is for
AcelleMail has **three distinct webhook systems**, and they're often confused. This reference documents each, with the real event names from the Acelle source (per `config/webhook_events.php` and the `webhooks` migration) — not the invented event names some older third-party guides list.
| System | Direction | Use case | Configured at |
|---|---|---|---|
| **Customer-lifecycle webhooks** | Outbound (Acelle → your app) | SaaS billing events — when a customer signs up, changes plan, cancels | Admin → Webhooks |
| **Per-campaign webhooks** | Outbound (Acelle → your app) | When a specific campaign sends / errors | Campaign → Edit → Webhooks tab |
| **Sending-provider notifications** | Inbound (sending provider → Acelle) | Bounce + complaint events from SES / Mailgun / SendGrid | `/api/v1/notification/bounce` + `/feedback` (auto-configured per sending server) |
Pick the right one for your use case before reading further.
## System 1 — Customer-lifecycle webhooks (the SaaS billing system)
This is the system **most people mean** when they ask about Acelle webhooks. Used by SaaS operators to keep their CRM, analytics, or billing system in sync with Acelle's customer + subscription state.
Configure at **Admin → Webhooks → New Webhook**. Each webhook subscribes to one event and posts to a URL of your choice.
### Available events
Per `config/webhook_events.php` — this is the authoritative list:
| Event | When it fires | Params posted |
|---|---|---|
| `new_subscription` | A customer starts a paid subscription on a plan | `customer_id`, `plan_id` |
| `cancel_subscription` | A customer cancels (subscription remains active until period end) | `customer_id`, `plan_id` |
| `terminate_subscription` | A subscription ends (after cancel grace period, or hard end) | `customer_id`, `plan_id` |
| `change_plan` | A customer moves between plans | `customer_id`, `old_plan_id`, `new_plan_id` |
| `new_customer` | A customer account is created | `customer_id` |
| `automation_webhook` | A "webhook" action fires inside an Acelle automation flow | `automation_id` |
> **`subscriber.created`, `campaign.opened`, `campaign.clicked` etc. are NOT events in this system.** Older docs sometimes list them; they don't exist. For subscriber + campaign events, use system 2 (per-campaign webhooks) or poll the API.
### Webhook delivery shape
```http
POST https://your-app.example.com/webhooks/acelle
Content-Type: application/x-www-form-urlencoded
customer_id=123&plan_id=45
```
Plus any auth header you configured (see below).
### Webhook configuration
The webhook form lets you set:
- **Name** — your label
- **Event** — one of the six above
- **Request method** — POST (default), GET, PUT, PATCH, DELETE
- **Request URL** — your endpoint
- **Authentication** — None, Bearer Token, Basic Auth, or Custom Header
- **Headers** — extra headers (e.g. `X-Source: acellemail`)
- **Body type** — `form-urlencoded` (default), `JSON`, `raw text`
- **Body params** — the event payload params (auto-populated) or your custom mapping
- **Retry on failure** — number of retries + delay between attempts
- **Status** — Active / Inactive
A webhook only fires when its `status = active`. Disable to pause without deleting.
### Triggering an automation_webhook from a flow
Inside an [automation flow](https://acellesend.com/kb/articles/advanced-automation-triggers-and-conditions), you can add a "Webhook" action. When a subscriber reaches that step, the configured `automation_webhook` fires with the `automation_id` (and optionally subscriber merge tags in the body).
This is the bridge from automation flows to external systems — fire a webhook to your CRM when a lead reaches "qualified", or to Slack when a high-value subscriber takes a key action.
## System 2 — Per-campaign webhooks
For events about a *specific campaign* (sent, opened, clicked, bounced, complained, unsubscribed), use the per-campaign webhook system.
Configure at **Campaign → Edit → Webhooks tab** (or via the campaign-creation wizard). Each campaign can have multiple webhooks; each subscribes to one event.
### Available campaign events
The per-campaign webhook table (`campaign_webhooks`) supports:
- `campaign.sent` — campaign send completed
- `campaign.open` — a subscriber opened the email
- `campaign.click` — a subscriber clicked a tracked link
- `campaign.bounce` — a delivery failure (hard / soft)
- `campaign.complaint` — a spam complaint
- `campaign.unsubscribe` — a recipient unsubscribed via the campaign
Payload includes the subscriber email, campaign uid, and event-specific fields (clicked URL, bounce reason, etc.).
### When to use this vs polling the API
| Pattern | Use when |
|---|---|
| Per-campaign webhook | You need real-time per-event reaction (push to Slack on bounce; sync to CRM on click) |
| Poll `/api/v1/campaigns/{uid}/...-log/download` | You need a batch import of all events for a campaign; or your app can't accept inbound HTTP |
For most external-system integrations, webhooks win — they're real-time and lower-cost than polling.
## System 3 — Sending-provider inbound notifications
The third system is for **inbound** webhooks — your sending provider (Amazon SES via SNS, Mailgun event hooks, SendGrid event webhook) posts bounce + complaint events to AcelleMail.
You usually don't configure these directly — Acelle auto-configures them when you set up the sending server (e.g. SES SNS topic + subscription is created during the SES sending-server wizard).
Routes:
- `POST /api/v1/notification/bounce` — receives bounce events
- `POST /api/v1/notification/feedback` — receives spam-complaint events
If you're building a custom sending provider integration, you'd POST events to these endpoints in the documented format. Otherwise, ignore — Acelle handles it transparently.
## Signature verification (where applicable)
For the **System 1 customer-lifecycle webhooks**, signature verification depends on what auth method you configured:
- **Bearer Token** — Acelle sends `Authorization: Bearer
`. Your endpoint checks the header matches the token you set. Simple, recommended.
- **Basic Auth** — Acelle sends `Authorization: Basic `. Your endpoint validates as usual.
- **Custom Header** — Acelle sends a custom header with a static value (e.g. `X-Webhook-Secret: my-shared-secret`). Verify equality with constant-time comparison.
Acelle's webhook system does NOT use HMAC signature on the body by default (unlike Stripe / GitHub). The auth header is the entire security mechanism. **Make sure your endpoint is HTTPS-only** so the auth header isn't exposed in transit.
If you need HMAC body signing, implement it via the **Custom Header** option — configure a header that contains the HMAC of the body computed in a Laravel listener you add via [extending source](https://acellesend.com/kb/articles/extending-acellemail-source-code).
## Retry behaviour
The webhook config lets you set:
- `setting_retry_times` — how many times to retry on non-2xx response
- `setting_retry_after_seconds` — wait time between retries
Recommended defaults: **3 retries with 60-second backoff**. Past 3 retries, the webhook is marked failed and won't fire again until manually re-enabled.
Your endpoint MUST:
- Return `2xx` within 30 seconds to count as success
- Be **idempotent** — Acelle may retry on transient failures; your endpoint should handle duplicate deliveries gracefully (key on `customer_id + event + timestamp`)
- Acknowledge quickly + process async — if your processing takes > 5s, accept the webhook, enqueue a job, return 200 immediately. Slow webhook handlers cause retry storms.
## Verifying webhooks work
```bash
# 1. Set up a temporary catch-all endpoint at https://webhook.site/
# (or use ngrok to forward to localhost)
# 2. Configure a webhook in Admin → Webhooks → New
# Event: new_customer
# URL:
# 3. Trigger the event — create a new test customer in the admin
# 4. Check webhook.site — you should see the POST with customer_id in the body
```
If nothing arrives:
- Check **Admin → Webhooks → Logs** for the delivery attempt and the response code Acelle saw
- Verify your endpoint returned `2xx`
- Verify webhook status is "Active"
- Check the queue is processing (webhooks are dispatched via the same queue as the rest of Acelle — see [Setting Up Queue Workers](https://acellesend.com/kb/articles/setting-up-queue-workers-and-cron-jobs))
## Common issues
| What you see | Likely cause | Fix |
|---|---|---|
| No webhook fires when expected | Webhook status = Inactive, or event mismatch | Verify status is Active; verify the event matches what you actually triggered |
| Endpoint receives one webhook many times | Endpoint returned non-2xx; Acelle retried | Make endpoint return 2xx faster; or fix the underlying issue causing the error response |
| Webhook payload missing custom fields | Customer-lifecycle webhooks only carry `customer_id` / `plan_id`. Subscriber data isn't included | Use `customer_id` to fetch the customer via API for additional data |
| Webhook arrives without auth header | Auth method = None | Reconfigure with Bearer / Basic / Custom Header |
| Endpoint says "signature invalid" | You enabled HMAC verification but Acelle doesn't ship HMAC | Use header-based auth instead, OR implement HMAC via a custom listener (extending source) |
| Webhooks back up after a sending storm | Queue worker pool saturated | Increase worker numprocs (see [scaling guide](https://acellesend.com/kb/articles/scaling-for-100k-emails-per-day)) |
| Per-campaign webhook fires before "sent" event for transactional sends | Race condition between send + tracking event | Process events idempotently; don't assume strict ordering |
| Need a subscriber.created event | Doesn't exist in customer-lifecycle webhooks | Use per-campaign webhook for `campaign.sent`, OR poll the subscribers API for new records |
## FAQ
**Why no `subscriber.created` event?** Acelle's customer-lifecycle webhook system was designed for SaaS billing — it covers events the operator cares about (new customer, plan change, cancellation), not events the customer would care about (new subscriber on their list). For subscriber events, use the per-campaign webhook system (system 2) or poll the API.
**Can I add custom events?** Yes — fire a custom event from a Laravel listener (added via [extending source](https://acellesend.com/kb/articles/extending-acellemail-source-code)), then add it to `config/webhook_events.php`. It'll appear in the webhook config UI.
**Do webhooks count against API rate limits?** No — webhooks are outbound from Acelle, not API calls from your code.
**Can the webhook payload be JSON instead of form-urlencoded?** Yes — set "Body type" to JSON in the webhook config. The same param keys are posted, just JSON-encoded.
**How do I retry a manually-failed webhook?** Admin → Webhooks → Logs → click the failed delivery → "Retry". Or trigger the original event again.
**Where can I see what URL Acelle is calling?** Admin → Webhooks → click the webhook → see configured URL + recent delivery log.
**Can I forward webhook payloads to multiple endpoints?** Configure multiple webhooks for the same event, each with a different URL. Each fires independently.
## Related articles
- [Getting Started with the AcelleMail REST API](https://acellesend.com/kb/articles/getting-started-with-the-acellemail-rest-api) — for polling the API as an alternative
- [REST API Authentication and Endpoints](https://acellesend.com/kb/articles/rest-api-authentication-and-endpoints) — full endpoint reference
- [Extending AcelleMail Source Code](https://acellesend.com/kb/articles/extending-acellemail-source-code) — adding custom events / listeners
- [Setting Up AcelleMail as a SaaS Platform](https://acellesend.com/kb/articles/setting-up-acellemail-as-a-saas-platform) — webhooks pair with SaaS use case
- [Advanced Automation Triggers and Conditions](https://acellesend.com/kb/articles/advanced-automation-triggers-and-conditions) — fire webhooks from automation flows
- [Setting Up Queue Workers and Cron Jobs](https://acellesend.com/kb/articles/setting-up-queue-workers-and-cron-jobs) — webhook delivery uses the queue
- [Using API Triggers for Custom Automation Workflows](https://acellesend.com/kb/articles/using-api-triggers-for-custom-automation-workflows) — the inverse (your app calls Acelle)
- [Configuring Amazon SES with AcelleMail](https://acellesend.com/kb/articles/configuring-amazon-ses-with-acellemail) — SNS notification setup for inbound (system 3)
---
# Preheader Text — The Hidden Conversion Booster in AcelleMail
> After the subject line, recipients see the preheader — the gray text snippet that follows. Setting it explicitly can lift open rates 5-10% over the auto-extracted default. This guide walks the AcelleMail field + the writing patterns.
- Canonical URL: https://acellesend.com/kb/articles/email-preheader-text-the-hidden-conversion-booster
- Author: Sofia Lindqvist, Email Marketing Editor
- Category: Email Marketing — Campaign creation, templates, A/B testing, personalization, scheduling
- Content type: tutorial · Difficulty: beginner
- Tags: Acellemail
- Published: 2026-04-03 · Last updated: 2026-08-15
- Reading time: 6 min
- Publisher: AcelleMail Knowledge Base, https://acellesend.com/kb
---
## What the preheader is
The preheader is the gray text shown immediately AFTER the subject line in most inbox lists. Examples:
```
Inbox preview:
─────────────────────────────────────────────
Brand Marketing · Last chance for 20% off
The sale ends tonight — your discount code...
─────────────────────────────────────────────
↑
Preheader
```
If you don't set the preheader explicitly, the inbox auto-grabs the first text from your email body. Usually this is garbage like "Trouble seeing this email? View in browser" — wasted real estate.
Setting an explicit preheader = 5-10% higher open rates, measured across many senders.
## Set the preheader in AcelleMail
In the campaign builder's **Setup** step, find the **Preheader** field. It sits next to the Subject:
Type your preheader text. Once typed:
Save. The campaign's metadata now includes both subject + preheader; receiver inboxes display both.
## Preheader writing patterns
Treat the preheader as a "second subject line" — different angle, complementary message:
| Pattern | Subject | Preheader |
|---|---|---|
| **Extend the subject** | "Last chance for 20% off" | "Discount ends tonight at midnight" |
| **Add urgency** | "Spring sale is live" | "1,247 customers already saved $40+" |
| **Soften with empathy** | "We noticed you're inactive" | "No pressure — just curious how you're doing" |
| **Curiosity tease** | "This is the email I should have sent last month" | "Better late than never. Let me explain..." |
| **Concrete benefit** | "Your weekly digest is here" | "5 actionable tips, 5 minute read" |
| **Personalization** | "{{ subscriber.first_name }}, here's your update" | "We've been working on something — hope it helps" |
## Length matters
Preheaders display ~40-100 characters in most inboxes:
```
Apple Mail iOS: ~50 chars before truncation
Gmail desktop: ~80 chars
Gmail mobile (Android): ~55 chars
Outlook desktop: ~60 chars
Yahoo: ~70 chars
```
Aim for 40-80 chars. Front-load the most important words.
## Verify in Preview
After typing the preheader, click **Preview** in the campaign builder:
The preview shows the full email body but NOT the inbox-preview format. For the actual recipient-side inbox view:
1. Click **Send test** → send to your own personal Gmail / Outlook
2. Open the test in each client
3. Verify the preheader text is what you typed (not the auto-extracted default)
In mobile view:
## Common UI signals + fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Preheader field grayed out | Selected campaign template overrides preheader | Some templates hardcode preheader; remove the override in template settings |
| Preheader saved but inbox shows "View in browser" | Preheader text contains hidden HTML / image alt text first | Verify preheader is plain text only |
| Preview shows preheader, real inbox doesn't | Inbox auto-extracted first body text instead | Add hidden preheader markup at top of email body (advanced) |
| Mobile preview truncates the preheader | Too long | Cut to 40-50 chars front-loaded |
| Preheader includes merge tags that don't resolve | Tag name mismatch | Use `{{ subscriber.first_name | default('there') }}` with fallback |
| Test send shows preheader correctly in 3 of 4 clients | Client-specific auto-extraction differences | Lengthen the explicit preheader to 80+ chars to ensure all clients use it |
## Common preheader mistakes
| Mistake | Why it hurts |
|---|---|
| Leaving preheader blank | Inbox auto-extracts garbage ("View in browser") |
| Repeating the subject verbatim | Wasted space; no incremental signal |
| Putting the unsubscribe link in preheader | Recipient sees "unsubscribe" before opening — reduces open rate |
| Cramming 200+ chars | Most gets truncated; first 40 chars are all that matter |
| Using emoji-only preheader | Some clients render as boxes; not all support emoji |
| Generic ("Hi there!") | Provides no incremental signal |
## What to put in the preheader
Best uses (ranked by reliability):
1. **Restate the benefit + add urgency** — "Sale ends tonight"
2. **Show social proof** — "1,247 customers already saved"
3. **Hint at content** — "5 actionable tips inside"
4. **Tease curiosity** — "Wait until you see #3..."
5. **Personalize** — "Maria, your update is ready"
Worst uses:
- Generic greeting ("Hello!")
- Sender reminder ("From Brand")
- Already-in-subject information (redundant)
- Unsubscribe link (kills open rate)
- "View in browser" (signals automation; lowers trust)
Advanced: hidden preheader markup + A/B testing preheaders + per-segment preheader personalization
**Hidden preheader markup** (for ensuring the right text appears even when inboxes auto-extract):
Most email templates include hidden preheader text at the top of the body:
```html
Your preheader text here. Cannot exceed ~80 chars to avoid truncation.
```
Then add invisible filler to push the actual email content:
```html
(etc — pad with zero-width-non-joiner)
```
The inbox extractor reads the first ~80 chars; recipients see only the visible email body.
AcelleMail's builder handles this automatically when you set the Preheader field. For raw HTML mode, add it yourself.
**A/B testing preheaders:**
If your subject lines are well-optimized, the next ROI lever is preheader testing:
1. New campaign → A/B test type
2. Variant A: "Sale ends tonight"
3. Variant B: "1,247 customers already saved"
4. Same subject + same body for both
5. Test on 20% sample; winner sends to 80%
Subject + preheader together = "what they see before opening." Combined optimization yields compound gains.
**Per-segment preheader personalization:**
For sophisticated segmentation, vary the preheader by audience tag:
```
Engaged segment: "You're one of our most active subscribers"
At-risk segment: "We've missed you — here's something to come back"
New segment: "Welcome — here's the catch-up you've been waiting for"
```
In AcelleMail, this requires per-segment campaign splits (one campaign per segment with appropriate preheader). Some senders use dynamic Liquid in the preheader:
```
{% if 'vip' in subscriber.tags %}VIP early access — 24h before everyone else
{% else %}Spring sale starts now{% endif %}
```
But preheader display from receiving clients can be unpredictable with dynamic content — test before relying on this.
**Preheader for transactional emails:**
For password resets / receipts / order confirmations, the preheader should:
- Mention the action briefly ("Password reset link inside")
- NOT include sensitive details (not "Your code: 123456" — visible in inbox preview = security issue)
- NOT include the unsubscribe link (transactional emails don't have one)
```
Transactional subject: "Your password reset link"
Transactional preheader: "Click below; expires in 30 minutes"
```
**Multi-language preheaders:**
For multilingual senders:
```
{% if subscriber.locale == 'es' %}Última oportunidad: 20% de descuento
{% else %}Last chance: 20% off{% endif %}
```
Test in Spanish-speaking + English-speaking client previews to ensure render correctly.
## Related articles
- [Your first email campaign in AcelleMail](https://acellesend.com/kb/articles/creating-your-first-email-campaign-in-acellemail)
- [Email subject line formulas that work](https://acellesend.com/kb/articles/email-subject-line-formulas-that-work)
- [Email template design best practices](https://acellesend.com/kb/articles/email-template-design-best-practices)
- [A/B testing email subject lines](https://acellesend.com/kb/articles/ab-testing-email-subject-lines-for-better-open-rates)
---
# Build a Signup Form and Embed It on Your Site
> AcelleMail has a drag-and-drop visual builder for signup forms with 4 popup layouts and 5 display triggers (immediate, delay, exit intent, on click, first visit). Walkthrough with real screenshots of every panel.
- Canonical URL: https://acellesend.com/kb/articles/creating-effective-signup-forms-and-landing-pages
- Author: Ryan Walsh, Audience & Analytics Editor
- Category: List Management — Segments, tags, import/export, double opt-in, verification, hygiene
- Content type: tutorial · Difficulty: beginner
- Tags: Segmentation, Double Opt In, Custom Fields
- Published: 2026-04-02 · Last updated: 2026-08-15
- Reading time: 10 min
- Publisher: AcelleMail Knowledge Base, https://acellesend.com/kb
---
## What this is for
You want to turn your website traffic into mail-list subscribers. AcelleMail has a visual form builder under **Forms** in the left sidebar — drag-and-drop, 4 popup layouts out of the box, 5 display triggers (immediate, after delay, on exit intent, on element click, first visit only), and a one-click way to publish the embed code into a connected website.
This walkthrough shows every panel of the builder and tells you what each setting actually does in production.
## Before you start
- **Decide which list new signups will land in.** Every form is bound to one list at creation time. If you don't have a list yet, create one in **Lists → + New list** first — you can't bind a form to a list that doesn't exist.
- **Know your minimum fields.** AcelleMail's form templates default to Email + First name + Last name + Company + Address + Phone + Web — way too many for a typical signup. Plan to remove what you don't need before publishing.
- **A connected website is optional.** You can publish a form and grab its HTML embed code without ever connecting a website. The "Connect to website" feature is for hosted/managed sites where AcelleMail can inject the popup script for you.
## Step 1 — Open the Forms section
Click **Forms** in the left sidebar (under *Audience*). The URL is `/rui/forms`.
You see three things:
- **Three action cards** — *Create a signup form*, *Connect to website*, *Embed on page*. These are the same three things you'll do for every new form; the cards just deep-link into each step.
- **Stats row** — total forms, how many are published vs draft, how many connect to a website.
- **Forms table** — every form you've created, with its connected list, status (Published / Draft), website connection, and trigger (e.g. *On click*, *Not connected*). Each row has a **Build** button that re-opens the visual editor.
Click the green **+ Create form** button in the top right.
## Step 2 — Pick a list and a template
A modal slides in. AcelleMail asks for the bare minimum it needs before opening the builder.
Three fields, in order:
- **Form name** — what appears in the forms table and in the campaign builder later. Use something concrete like *"Homepage hero — newsletter"* or *"Footer minimal"*, not the default *"Untitled form"*.
- **Connect to list** — the mail list that receives new signups. Required. You can change it later in *Settings*, but new signups before the change land in the original list.
- **Form template** — there are two tabs: **Base** (4 popup layouts ship with AcelleMail) and **Extended** (custom templates your admin creates). The 4 base templates are *Popup Form Banner*, *Popup Form Right Banner*, *Popup Form Top Banner*, and *Popup Form Bottom Banner* — all variants of where the popup anchors on the page.
Click **+ Create form**. AcelleMail saves a draft and opens the visual builder.
## Step 3 — Drag fields onto the canvas
You land on the builder. There are three things on screen worth knowing.
- **Live preview** in the centre. The browser-mockup chrome shows where the form will sit relative to a real page. Anything you drag from the right panel appears here.
- **Form Fields panel on the right.** Lists every field on the connected mail list — Email is always required and pre-included. Drag any other field onto the canvas to add it. Drag a field off the canvas to remove it. The **Load list defaults** button repopulates the canvas with one widget per list field — a fast reset.
- **Top bar.** From left: form name + status badge (DRAFT / PUBLISHED), responsive previews (desktop / tablet / mobile), undo / redo, **Preview**, **Publish** / **Unpublish**, **Save**, **Close**. The tip at the top of the right rail — *"Just drag & drop the widget into the page content to insert!"* — is the only instruction the builder gives you.
**The two things you'll almost always do first:**
1. Click into the *Welcome to {{LIST_NAME}}!* heading and rewrite it. The `{{LIST_NAME}}` token auto-fills with the connected list's name; replace it if you want fixed copy.
2. Drag off fields you don't need (Address, Phone, Web are usually overkill for a newsletter signup). The fewer fields, the higher conversion.
## Step 4 — Change the layout (or fine-tune the design)
The right rail has three vertical tabs: **Layouts**, **Design**, **Settings**. Click **Layouts** to switch the popup's anchor position without losing your field work.
The 4 layouts are different anchor positions:
| Layout | Where the popup appears | Typical use |
|---|---|---|
| **Popup Form Banner** | Centred modal overlay | First-visit lead magnets |
| **Popup Form Right Banner** | Anchored to the right edge | Slide-in offers (less intrusive) |
| **Popup Form Top Banner** | Pinned to the top of the page | Announcement strips |
| **Popup Form Bottom Banner** | Pinned to the bottom | Cookie-bar-style sign-ups |
Swap layouts at any time — your field work carries over. **Design** is the middle tab and gives you finer control over fonts, colours, and spacing.
Don't forget to preview narrow viewports — click the **mobile** icon in the top bar.
Always check mobile before publishing. The default Base templates are responsive, but custom layouts and long field labels can wrap badly on narrow screens.
## Step 5 — Configure when the popup fires
Click the **Settings** tab on the right rail. This is the most important panel for popup forms — it controls *when* the form appears to visitors.
What each setting does:
- **Form name** — change it any time, no signups affected.
- **Mail list** — swap which list receives new signups. New submissions after the save go to the new list; existing signups stay in their original list.
- **Overlay opacity** — only relevant for the centred *Popup Form Banner* layout. 0% = transparent background; 100% = fully black overlay. 40–60% is the typical sweet spot.
- **Display trigger** — the heart of the popup. Five options:
| Trigger | What happens | When to use |
|---|---|---|
| **Immediately** | Popup shows on page load | Lead-magnet landing pages where the offer IS the page |
| **After delay** | Wait N seconds (you pick) | Lets visitors see your content before being asked to subscribe |
| **On exit intent** | Mouse leaves the viewport | Cart abandonment, last-chance offers — desktop-only |
| **On element click** | When a specific element (by ID or CSS selector) is clicked | "Subscribe" links scattered across your site that all open the same popup |
| **First visit only** | Cookie-based — popup shows once per browser | Aggressive lead-gen without annoying returning visitors |
When you pick *On element click*, an extra **Element ID or selector** input appears — paste the element ID (`abc123` for `id="abc123"`) or any valid CSS selector (`.subscribe-link`).
Click **Save settings** when you're done. Settings are not part of the canvas — they save independently from your design.
## Step 6 — Preview, publish, and embed
When the form is ready:
1. Click **Preview** in the top bar — opens a real rendered version in a new tab. Click around as if you were a visitor.
2. Click **Publish**. The status badge switches from DRAFT to PUBLISHED, and AcelleMail makes the form's URL + embed snippet available.
3. To **embed on your own site**: from the forms list, click the form's row menu → **Embed on page**. AcelleMail gives you a small script tag to paste before the closing `
```
Combined with the `@media (prefers-color-scheme: dark)` in Pattern 2:
```css
@media (prefers-color-scheme: dark) {
.logo-light { display: none !important; }
.logo-dark { display: inline-block !important; }
}
```
In clients that respect the media query: only one logo renders. In clients that ignore it: both render (uncommon, looks slightly awkward but not broken).
### Pattern 4 — Avoid pure-white logos with transparency
Why: a white-fill PNG with transparent background renders fine on white. On dark mode, it becomes "white shape on dark background" — readable. But if the client auto-inverts (Gmail Android), the white fill becomes black-on-dark = invisible.
**Three safer alternatives:**
1. **Dual-logo swap** (Pattern 3) — explicit + reliable
2. **Solid-color background behind the logo** — wrap the IMG in a `
