Buttondown is a low-fuss newsletter service, and the Buttondown WP plugin is correspondingly minimal: it caches the API key and tag list in wp_options under buttondown_settings, stores per-form tag mappings in wp_postmeta (commonly _buttondown_tag), and keeps a short sync log of the last few hundred subscribe events so transient failures can be retried.

The default admin shows a settings page and a per-form meta box. There's no aggregated view of which posts capture opt-ins to which Buttondown tag, which mappings point at tags renamed upstream, or which subscribe events stalled. Buttondown's strength is its simplicity, but that simplicity also means there's no native operational dashboard inside WordPress.

SleekView reads the cached tag list, the per-form _buttondown_tag meta, and the sync log, then joins it all to wp_posts. Form attribution, stale-tag detection, and retry queues become row-level operations; inline retries call the plugin's own API client so Buttondown sees the same calls it would on a normal cron run.

Buttondown's pitch is simplicity: a clean editor, fair pricing, no upsell to a marketing-automation stack. The WordPress plugin matches that posture, doing one thing well and stopping there. That's the right design choice for the install wizard but leaves a gap once a site grows to dozens of forms across dozens of tags.

The plugin maintains the data needed to audit the integration, cached tag list, per-form mappings, sync log, but doesn't aggregate it into a workspace because doing so would expand the plugin's surface area beyond its core mandate. SleekView fills that gap from the outside: it reads what the plugin already stores, joins it to wp_posts, and gives the team a row-level view with retries routing through the plugin's own API client. For solo publishers and small teams running Buttondown alongside a serious WordPress site, that workspace is what keeps the sync layer auditable without forcing Buttondown itself to grow features it doesn't want to grow.