SendPulse stores subscribers in its hosted account. The WordPress plugin is the bridge: API credentials and mailing-list mappings live in wp_options under keys like sendpulse_settings, and per-form mappings sit on each form's wp_postmeta. When logging is enabled the plugin writes a small event record per push (a dedicated table or rolling option entry).

The default admin screens are built around configuration: connect the account, map a form, save. They do not give an operations table over what shipped. "Which signups today failed to reach SendPulse, which list received them, and which mailing automation got triggered" is not a one-click view. Per-list mapping audits after rebranding a campaign require clicking through each form.

SleekView reads the connector's options and event log directly. Signups become rows with mapped address_book_id, push status, and the API response. Mapping overview renders every form's destination at once. Bulk retry calls the plugin's own push code, so the API behaviour matches a normal signup.

SendPulse competes on being multi-channel: email, SMS, web push, chatbots. The WordPress connector covers the email side of that surface, pushing signups into mailing lists so the campaigns set up in SendPulse can do their job. The architecture is correct: the plugin should be a bridge, not a CRM.

The honest tradeoff is that the WordPress side stays minimal by design. A few options, a thin log, a few hooks. Operators only think about it when something quietly stops working.

A list got renamed and the old address_book_id still maps to the new form, the API key rotated, a rate limit kicked in mid-campaign. SleekView pulls the existing option and log records into one workspace so the cross-form picture is visible to the marketing team without a developer in the loop, and so admins can fix the queue inline when the API responds again.