Maildroppa

• After pairing, classic and block checkout collect the server-side cart, product and variant IDs, names, quantities, prices, currency, checkout ID, revision, activity time and entered email address. Signed updates send those facts and a personal recovery link from WordPress to https://api.maildroppa.com/integrations/woocommerce/plugin/checkouts. This is separate from newsletter signup and does not itself subscribe the visitor. Maildroppa applies the account's configured reminder permissions and sending rules; connecting the plugin does not activate a reminder automation.
• WordPress retains these checkout facts for up to 30 days from the original checkout. Recovery tokens and immutable delivery bodies are encrypted using the shop credential. Delivery attempts are limited to eight attempts and 24 hours. WP-Cron drives delivery and expiry cleanup; missed cron runs delay physical deletion. Before each native reminder, Maildroppa requests the current checkout through the signed WordPress /wp-json/maildroppa/v1/woocommerce/checkouts/state endpoint. A closed, empty, expired or unavailable checkout cannot authorize a reminder.
• Opening a personal recovery link displays a page without changing the cart. A deliberate form submission restores available items at current prices, and replacing an existing cart requires confirmation. Saved payment, login and billing details are not restored. A changed email address, completed order, expired link or revoked pairing prevents reuse of the old link. Disconnect invalidates access and pending technical work while retaining durable checkout facts under their existing expiry.
• Product pages can display a purpose-specific availability form for an unavailable simple product or selected variant when enabled in Maildroppa. WordPress requests the signed form configuration and sends the selected product/variant IDs, email address, language and server-observed visitor IP address to /integrations/woocommerce/plugin/back-in-stock/requests. Maildroppa uses its existing confirmation and product-availability notification flow. This does not subscribe the visitor to newsletters. The browser submits to WordPress; this form does not load the remote hosted-form runtime.
• WordPress personal-data export includes the person's current checkout facts and any matching earlier recipient still present in an outstanding encrypted delivery, without recovery links, tokens or secrets. Explicit erasure removes matching local checkout and delivery copies. A signed, encrypted erasure request between Maildroppa and WordPress binds the source, original credential and request ID. Local completion and outstanding remote completion are distinct. Encrypted confirmation work expires after 24 hours and then requires source-specific manual completion; minimal receipts contain only references, hashes and removal counts.

With WooCommerce active, administrators can explicitly pair the shop under Maildroppa > Settings > WooCommerce. Pairing sends a one-time code, the canonical shop URL and plugin/protocol versions to https://api.maildroppa.com/integrations/woocommerce/plugin/pairing. The pairing request is authenticated with the existing API key; a code from another Maildroppa account is rejected. The separate shop credential is encrypted in WordPress and never exposed to the browser. Signed status and revocation messages are sent to /integrations/woocommerce/plugin/events, with event IDs, timestamps, revisions, the installed plugin version and the shop URL. Non-production WordPress environments do not transmit shop status or collect checkout signups. A site/account/API change blocks old work until deliberate reconnection. When explicitly enabled, classic and block checkout display an optional, initially unchecked newsletter checkbox with the configured consent text and topic labels. Only an opted-in, successfully submitted checkout queues the billing email and first name, selected topic IDs, displayed agreement, checkout source URL and submission time. The WordPress server sends these to the authenticated idempotent /subscribers/wordpress-signup-requests/{requestId} endpoint; central double opt-in applies. Address, phone, payment details and purchased products are excluded. Maildroppa signup settings are separate from the native WooCommerce order connection. Each checkout signup also identifies its original shop credential; Maildroppa verifies its owner and active permission before accepting the signup. Revocation in the app therefore prevents further signup acceptance immediately. Status checks refresh the local display every six hours; status is no longer current after 24 hours. This uses the same eight-attempt limit, 24-hour signup expiry, Retry-After handling and 30-day failed-record retention as the other form integrations. WordPress personal-data export/erasure covers the local signup queue. Cron is required for delivery, status checks and cleanup. Changing consent/topics or revoking/replacing the pairing removes queued shop signups. Deactivating WooCommerce stops queued signups; they end through the same bounded queue. Regular plugin updates preserve shop permission and pending signed status bytes. Opted-in uninstall and explicit local account cleanup remove the shop configuration and credentials. The module supports HPOS and both checkout presentations. Checkout collection and cart recovery require the matching version 1.4 backend contract; activate reminder automations deliberately in 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, WPForms or WooCommerce). 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 or WooCommerce shop permission 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 or a WooCommerce shop permission 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.