XeroWP
Maildroppa
Maildroppa

Maildroppa

0/5 (0 ratings) — active installs Updated Oct 24, 2026
Email Marketingnewsletterrsssignup formswoocommerce
Download v1.4.0
Manage subscribers, filter by status and tags, and follow subscriber growth. All names, email addresses and figures shown are fictional examples.

Manage subscribers, filter by status and tags, and follow subscriber growth. All names, email addresses and figures shown are fictional examples.

Maildroppa connects WordPress and WooCommerce to your Maildroppa account. Add signup forms, manage subscribers, turn blog posts into RSS newsletters, and connect your shop for optional checkout newsletter signup, cart recovery, and back-in-stock alerts.

The plugin is free. A Maildroppa account is required; free and paid plans are available. See Maildroppa pricing.

Features

  • Place active inline Maildroppa forms with a shortcode, Gutenberg block, or classic widget.
  • Build theme-styled signup forms (native WordPress HTML) from an active inline Maildroppa form and style them with your WordPress theme.
  • Place active popup and slider forms on all or selected pages/posts, or exclude selected pages/posts.
  • Open published page forms through their Maildroppa landing-page link.
  • Manage subscribers, fields, tags, and segments from WordPress.
  • Preview RSS or Atom feeds and create, edit, activate, pause, resume, test, check, and archive RSS newsletters inside WordPress.
  • Review feed-check history and release or cancel generated RSS newsletter issues without leaving WordPress.
  • Configure scheduled, instant, or item-threshold delivery, segments, sender profiles that can currently send, email copy, and review or automatic release.
  • Pair WooCommerce and offer optional newsletter signup in classic or block checkout, with HPOS support and central double opt-in.
  • Offer an optional, unchecked newsletter signup in Contact Form 7 and WPForms, with explicit field and topic selection and central double opt-in.
  • Optionally deliver selected WordPress user events to Maildroppa automations through a persistent queue with limited retries and age-based expiry.
  • Optionally expose signed Maildroppa subscriber events as replay-protected WordPress actions.

WooCommerce

Use the direct WooCommerce connection in Maildroppa to sync orders, order history, and product data. Order and product sync does not require this WordPress plugin. Install and pair the plugin to add these shop features:

  • Offer an optional, initially unchecked newsletter signup in classic or block checkout, using your configured consent text, subscription topics, and Maildroppa double opt-in flow.
  • Send checkout updates to Maildroppa for cart-reminder automations that you deliberately configure and activate. Connecting the shop does not automatically enable reminder emails.
  • Let customers return through a personal recovery link and confirm restoring available cart items at current prices. Payment, login, and billing details are not restored.
  • Display back-in-stock request forms for unavailable simple products and selected variations. Product alerts require their own email confirmation and do not subscribe customers to newsletters.

Supports classic and block checkout, High-Performance Order Storage (HPOS), and the classic WooCommerce order store. WooCommerce is optional; the other WordPress features work without it. Background delivery requires WordPress cron or a working hosting cron setup.

External services

This plugin requires Maildroppa, a third-party email marketing service operated by Maildroppa. The following connections occur only for the described features.

Maildroppa API

  • When an administrator tests the connection or manages Maildroppa data in WordPress, the WordPress server sends the configured API key to https://api.maildroppa.com. Depending on the selected action, the request also contains resource IDs and subscriber email addresses, names, statuses, custom field values, tag assignments, field/tag/segment definitions, segment expressions, search/filter criteria, or pagination parameters. Maildroppa uses this data to authenticate the account and perform the requested email-marketing action.
  • Opening Maildroppa > Subscribers requests account-wide daily subscriber counts for the last 30 calendar days from the Maildroppa API. The request contains the API key, date range and report interval. Successful reports are cached locally for five minutes, separately for each account and API connection. The chart shows confirmed subscriber totals, not signups attributed to this website.
  • Opening any connected Maildroppa admin page, or connecting or replacing an API key, requests https://api.maildroppa.com/account. Maildroppa returns the stable account ID, account name and owner email shown in the admin header. WordPress stores a hash of that ID and the API origin to bind its cached forms and queued events to the account. Rotating a key within the same account preserves this binding. Switching to a different account is blocked while local forms, event settings, queued deliveries, or account webhooks still belong to the previous account.
  • Opening the forms report requests /report/form with the selected date range and form IDs to show signup counts by form. The subscriber report uses /report/subscriber-status-total. Manually requesting double opt-in sends the entered subscriber data, the consent text and a consent source containing the WordPress administrator ID and UTC timestamp; Maildroppa may send a confirmation email.
  • Each request from the WordPress server identifies the plugin and its version, the WordPress version, and the site’s home URL in its HTTP User-Agent header. This also applies to requests made by scheduled background tasks.
  • When hosted forms are placed on the site or managed in the admin screens, the WordPress server reads the form definitions, names, types, statuses, placement options, and published page URLs from the Maildroppa API and stores this metadata in the local WordPress options table. It refreshes the cache in a scheduled background request when it becomes stale; a public page view of a page with a placed hosted form can schedule that refresh. The cache normally expires after five minutes, may be used for up to seven days during an API failure, and failed refreshes are retried after a five-minute backoff. The cached data is used to populate form-placement controls and to validate configured placements; it does not contain subscriber records.
  • When an administrator opens or manages RSS newsletters, the WordPress server requests newsletter data, the available subscription topics, and sender-profile delivery status from https://api.maildroppa.com. Feed previews send the entered public feed URL. Creating or editing a newsletter sends its name, source/site/feed URLs and feed title, delivery schedule or threshold, selected segment, sender-profile and subscription-topic IDs, subject, email content, item limit, and approval policy. Status, feed-check, issue-history, release, cancellation, test-email, and archive actions send the selected newsletter and, where applicable, issue ID. Maildroppa uses this data to create and operate the requested RSS newsletter. Maildroppa servers fetch the configured public RSS feeds themselves.
  • When an administrator deliberately sends a support request, the WordPress server sends the entered administrator name, email address, and message to https://api.maildroppa.com/contact so Maildroppa can answer it. The “Include technical details” checkbox is selected by default and can be cleared before sending. When selected, the message also includes the plugin, WordPress and PHP versions, whether automatic WordPress cron is enabled, the last observed Maildroppa cron run, and API-key validation status. The administrator can inspect these details in the form. The automatically attached details contain no API key or subscriber data; the support request does not send the API key for authentication.
  • When WordPress user events are explicitly enabled, the WordPress server stores each selected event in a local queue and sends the event name, user email address, occurrence time, idempotency key, and only the profile properties selected by an administrator to https://api.maildroppa.com/events. Delivery runs in scheduled background requests, retries temporary failures a bounded number of times, and does not create a Maildroppa contact. Pending events expire 30 days after creation and will no longer be sent. Expired and permanently failed records, including the email address and selected properties, remain available for diagnosis for 30 days after failure; WordPress’s personal-data export and erasure tools include these records. Cleanup runs daily through WP-Cron while the plugin is active. Missed or disabled cron runs delay physical deletion; site operators must arrange regular WP-Cron execution. If an event cannot be queued, WordPress stores a diagnostic marker with event name, user ID, failure time, count and error message for at most 30 days, subject to daily WP-Cron cleanup. The queue has no fixed record-count limit. Maildroppa rejects events for people who are not Maildroppa subscribers and events without a matching automation; these are kept as failed records under the same retention.
  • When Maildroppa events in WordPress are explicitly enabled, the WordPress server sends the public WordPress receiver URL and selected event name to https://api.maildroppa.com/webhook-subscriptions. When the selected event occurs, Maildroppa sends a signed HTTPS request to that public receiver. The request contains the event ID and type, subscriber email and profile fields, tags, and event-specific form, confirmation, or tag details, together with timestamp, signature, event-ID, and delivery-ID headers. The plugin verifies the signature and acknowledges completed replays without running the event again during the 90-day retention period. Completed event IDs become eligible for deletion after 90 days for replay protection. Daily WP-Cron cleanup and incoming webhook requests remove expired records; missed cron runs can delay deletion. Disabling an event asks Maildroppa to stop sending it.
  • The API base URL can be changed by the site owner using the documented MAILDROPPA_API_BASE_URL constant or environment variable, or the maildroppa_api_base_url WordPress filter. If changed, API requests, including authenticated requests with the API key and the contact-form signup requests described below, go to the configured URL instead of https://api.maildroppa.com.

Optional Contact Form 7 newsletter signups

  • This integration requires Contact Form 7 and a connected Maildroppa service that supports WordPress signup requests. An administrator must enable it for each contact form, map the permitted input fields, select subscription topics, and provide the consent text. Opening its configuration requests available fields and topics from the Maildroppa API. Opening or saving enabled settings also sends an authenticated GET request to https://api.maildroppa.com/subscribers/wordpress-signup-requests to check whether the connected service supports this feature. The mapping, topic IDs and labels, consent text, and account/site binding are stored with the contact form in WordPress.
  • A visitor must select the optional, initially unchecked newsletter checkbox. Only after Contact Form 7 successfully sends the contact email does the plugin queue the newsletter signup. Demo mode and skipped email delivery are not supported. The plugin queues the mapped email address and other mapped field values, selected topic IDs, displayed consent text including topic labels, consent source containing the site URL and contact-form ID, submission time, and a random request ID. Unmapped fields, multi-line message fields and attachments are not forwarded by this integration.
  • Scheduled delivery sends the signup, submission time and request ID from the WordPress server to https://api.maildroppa.com/subscribers/wordpress-signup-requests/{requestId}, authenticated with the API key. Maildroppa uses this data to process the signup through the account’s default signup flow and determine whether to send a double-opt-in confirmation email. Queuing a signup does not itself confirm a subscription. The visitor browser sends the contact form to WordPress; it does not send this signup directly to the Maildroppa API or load the hosted Maildroppa form runtime for this checkbox.
  • Temporary delivery failures are retried with increasing delays, up to eight attempts for retryable failures. Pending contact-form signups expire after 24 hours. This signup queue accepts up to 5,000 retained signup records and a maximum queued payload of 64 KiB. Accepted requests are removed locally. When a signup expires or permanently fails, its queued signup payload is cleared; the email address, request identifier, timestamps, status and error details remain for diagnosis until eligible for deletion 30 days after failure. Administrators can delete failed records immediately, but cannot manually retry them; a new signup requires new consent. WordPress personal-data export and erasure include pending and failed queue records. Cleanup requires WP-Cron while the plugin is active; missed runs delay cleanup. Changing the account, site URL or matching integration configuration, or disabling that integration, prevents pending signups from being sent under the old configuration.

WPForms uses the same signup API and delivery queue as Contact Form 7. Only successful submissions with newsletter consent are forwarded. See the WPForms FAQ below for setup, transmitted data, retention and website attribution.

Hosted and native Maildroppa forms

  • On public pages where an administrator has placed a hosted form, the visitor browser loads executable JavaScript from https://form.maildroppa.com/md-form-loader.js and form styles from https://form.maildroppa.com. The browser requests these resources when it renders the page containing the form. The script then requests the selected form definition from https://api.maildroppa.com/form/{formId} using the form ID and a SHA-256 fingerprint (requires Web Crypto, normally available over HTTPS) derived from screen size, browser name and major version, and operating-system name and version. This loads and renders the selected hosted form and counts unique form views. The loader stores lastSeen{formId} in localStorage, loads images from https://static.maildroppa.com, and may load videos from YouTube, Vimeo or another URL configured in the form. Those providers receive the IP address and browser request headers when their resources load.
  • A native WordPress form uses HTML and styles delivered by this plugin. When a visitor opens a page containing the form, the visitor browser requests the current form definition, visitor-specific agreement, and legal links from https://api.maildroppa.com/form/{formId} using the same fingerprint. Native forms use a shorter non-cryptographic fingerprint if Web Crypto is unavailable or fails. This keeps required fields and consent aligned with Maildroppa and counts unique form views while the WordPress theme controls presentation.
  • Loading either form type already sends the form ID and fingerprint to Maildroppa, before submission. Maildroppa stores the IP address, form ID and fingerprint for daily unique-view counting; daily records become eligible for deletion on the following day.
  • When a visitor submits a hosted or native form, the browser sends the form ID, email address and other configured field values, the displayed subscription-topic IDs and labels, the IDs of topics the visitor selected, the agreement ID when consent is required, and the same fingerprint directly to https://api.maildroppa.com/subscribe. Normal HTTPS request data, including the visitor IP address, user agent, and any referrer information the browser permits, also reaches Maildroppa. Maildroppa uses this data to process the requested newsletter signup, topic choices, and related consent workflow.
  • Sites with a Content Security Policy must allow scripts and styles from https://form.maildroppa.com and connections to https://api.maildroppa.com for these forms, plus images from https://static.maildroppa.com and any configured video providers.
  • The public form loader URL can be changed by the site owner using the documented MAILDROPPA_PUBLIC_FORM_BASE_URL constant or environment variable, or the maildroppa_public_form_base_url WordPress filter. The maildroppa_public_form_loader_url filter can override the hosted loader script URL independently. If changed, hosted form scripts and styles load from the configured URL. Native form definitions and submissions use the API base URL. The hosted loader uses its own configured API origin.

Form and RSS previews

  • Opening a hosted-form preview in WordPress, including a preview embedded in the block editor, loads executable JavaScript from https://form.maildroppa.com/md-form-preview.js and styles from https://form.maildroppa.com/index.css into the administrator’s browser. This also happens when the form has not been placed on a public page. The preview requires administrator access and a valid WordPress nonce. WordPress requests the selected form’s preview data from the Maildroppa API using the API key and form ID, and supplies that data to the preview renderer. Native-form previews use the plugin’s local renderer and WordPress REST endpoints. Preview submissions are intercepted locally and do not send newsletter signups or confirmation emails. Resource requests still send normal browser request data, including IP address and user agent, to the resource host. A configured public form base URL also changes the hosted preview script and style origin.
  • Opening an RSS issue’s email preview first requests its content through the Maildroppa API …