Maildroppa

• Requires WPForms Lite or Pro and a connected Maildroppa service with the WordPress signup API. An administrator configures each form under Settings > Maildroppa in the WPForms builder. Available fields, topics and signup API availability are requested from the configured Maildroppa API, using the API key. Maildroppa stores the field mapping, topic IDs and labels, consent text, and account/API/site binding in separate WordPress metadata. This configuration is not included in WPForms exports or duplicated forms.
• The plugin adds an optional, initially unchecked newsletter checkbox before the submit button. JavaScript generates a random submission request ID before enabling it. Only successfully processed, non-spam submissions with consent queue the mapped signup fields, selected topics, displayed consent, source URL and form ID, and submission time. Name fields mapped to first name send the first-name component. Message fields and attachments are excluded. Contact form processing and WPForms notifications remain independent of newsletter consent.
• Delivery uses the same authenticated WordPress signup PUT endpoint, central double opt-in, retry schedule, 24-hour expiry, eight-attempt limit and 30-day failed-record retention as Contact Form 7. WP-Cron is required. Changes to account, form, mapping or consent and deactivation of WPForms stop queued requests. Failed signups cannot be restarted without new consent. Account reset and opted-in uninstall remove Maildroppa metadata without deleting WPForms forms.
• Update signup sources to register WPForms for future website signup attribution. The connected backend must support the WPFORMS integration type.

• Clicking "Update signup sources" sends authenticated PUT requests to https://api.maildroppa.com/wordpress-sites/{siteId} and /wordpress-sites/{siteId}/placements/{placementId}. These contain the site home URL, generated site and placement identifiers, form names, Maildroppa form IDs when applicable, and the integration type (hosted, native, Contact Form 7 or WPForms). WordPress stores the identifiers and source configuration with their account, API-origin and site binding until local cleanup or an opted-in uninstall. Registered forms send their placement identifier with future signups so Maildroppa can attribute them to this site; earlier and unattributed signups are excluded.
• Opening or paging through the website report sends the site identifier, a 7- or 30-day period and page number to /wordpress-sites/{siteId}/signups. Maildroppa returns signup email addresses, submission times, placement names, confirmation-email decisions and confirmation status, plus accepted and confirmed totals. The report is available only to authenticated administrators and is not cached publicly.
• Clicking "Create standard form" sends the entered form name and a stable request identifier in an authenticated PUT to /form-builder/wordpress-standard/{requestId}. This creates an inline form in the connected Maildroppa account; repeated requests for the same name on this site reuse that request identifier. The returned form ID is used to open the form editor in the Maildroppa app. Creating the form does not itself place it on the public website.

Maildroppa accounts are available for business use; see the Terms of Service. Yes. You need a Maildroppa account to create forms, generate an API key, and manage audience data from WordPress.

No. The key is encrypted with a stable per-installation key in WordPress and authenticated Maildroppa admin requests remain server-side. The settings field is masked by default.

Hosted and native WordPress forms use Maildroppa's public browser flow. Visitor submissions go directly from the browser to Maildroppa and are not proxied through the WordPress server.

Open Maildroppa > Get started. Restore the original maildroppa_encryption_key_v1 WordPress option from a trusted database backup to recover existing encrypted credentials. Never replace a working key or delete connection records to bypass recovery. If no account webhook depends on the damaged key, the page offers an explicit reset that removes the unusable local API key and generates a new encryption key. Forms, queued events and the stored account identity remain unchanged; reconnect with a key for that same Maildroppa account. If existing data has no recorded account identity and the old credential is unavailable, restore the original key from backup; a reset cannot prove that data's ownership. If webhooks exist, reset is blocked and the original key must be restored. Remote connections are never revoked automatically.

Reconnect the previous account first and remove its forms, integrations and queued events; a different account is blocked while this data exists. If the previous account is no longer accessible, remove the API key and use "Remove previous account data" under Maildroppa > Get started. This removes the data only from WordPress: webhook subscriptions are not revoked in Maildroppa, so delete them in the Maildroppa app if you still can.

Yes. Active inline hosted forms and configured theme-styled forms each have a dedicated Maildroppa block.

Yes. Active inline Maildroppa forms can also be placed in a classic WordPress widget area.

The plugin retries delivery at bounded intervals. Pending events expire after 30 days and cannot be sent or retried afterwards. Failed records can be diagnosed or deleted under Maildroppa > Settings > WordPress users, including when the API connection is unavailable. Retrying requires the original account and an event younger than 30 days. Failed records are eligible for deletion 30 days after failure, so an expired event can remain locally for about 60 days after creation. Daily cleanup depends on WP-Cron running while the plugin is active; missed cron runs delay deletion. The WordPress personal-data tools include these records.

Local data is preserved by default. Complete local cleanup must first be explicitly enabled under Maildroppa > Settings > Data & uninstall and is blocked while webhook subscriptions or reconciliation work remain. Remote Maildroppa data is never deleted by uninstall.

Yes. The plugin records completion after all listeners of the corresponding WordPress action return successfully. If a later listener fails or the request terminates, Maildroppa can retry the event and an earlier successful listener can run again. Each listener must use the stable event ID in its second action argument to prevent duplicate business effects. Replay protection after completion is not an exactly-once guarantee for custom listeners.

The optional debug setting in maildroppa_options logs failed API requests only when WordPress debug logging is enabled. It records method, redacted route, status and error ID; API keys, message bodies and subscriber email addresses are excluded. Keep debug logging disabled unless investigating a problem, restrict access to the log and delete it after diagnosis.

All PHP, JavaScript and CSS files are unminified source files; no build step is required. The bundled .mo and .json translation files are built from translation sources maintained in the development repository.