Clean up every bounced and blocked email address in one place

Build me an app that our marketing ops person opens once a week to keep our sending lists clean. Today our suppressed addresses are scattered across sending domains in Mailgun, which only shows them one domain at a time, and none of it is visible to anyone working in HubSpot. I want one screen that pulls it all together.

The main view is a single sortable table of every suppressed address across all of our sending domains. Build it by calling Mailgun List Domains to get every sending domain on the account, then fanning out across those domains with List Bounces, List Complaints and List Unsubscribes, and merging the results into one list where each row carries the address, the suppression type (bounce, complaint or unsubscribe), the sending domain it came from, the reason or error code, and the date it was suppressed. Follow Mailgun pagination on each list call so we get the full set, not just the first page. Give the table filters for suppression type, domain, reason code and date range, plus a free text search on the address, and let every column sort. Rows should be selectable so bulk actions can apply to a chosen set.

Across the top of that view, show a header strip with our deliverability headline numbers: account wide bounce rate and complaint rate from Get Account Total Stats, and a per domain breakdown from Get Account Domains Total Stats so it is obvious when one sending domain is dragging the account down. Let the person switch the strip between a few time windows, for example the last 7, 30 and 90 days.

Each row expands in place to answer the question "who is this address actually?". On expand, look the address up in HubSpot with Search Contacts and show the contact name, company, lifecycle stage, owner and last activity date if a match exists, or a clear "no CRM match" state if there is not. This is the whole point of the expansion: the team needs to spot when a suppressed address belongs to an active customer rather than a dead lead. For bounce rows, also pull the full record with Mailgun Get Bounce so the raw error string and bounce code are visible alongside the CRM identity.

Row actions let the person act without leaving the table. Re-check the address with Mailgun Validate Single Address and show the returned verdict inline. Lift the suppression with Delete Bounce, Delete Complaint or Delete Unsubscribe, whichever matches the row type, and remove or restyle the row once it succeeds. Write the outcome back onto the CRM record with HubSpot Update Contact, so marketing stops mailing addresses we know are dead. Ask for confirmation before any lift or CRM write, and surface Mailgun and HubSpot errors on the row itself rather than as a generic failure toast.

Add a "Triage these bounces" button that runs a background agent across whatever set is currently filtered or selected in the table. The agent should pull classification context with List Bounce Classification Stats and List Bounce Classification Bounce Logs, combine that with the reason codes and CRM identity already on each row, and sort every address into a category: likely typo (a misspelled domain or obvious fat finger, often worth correcting and reinstating), dead domain (the receiving domain no longer accepts mail, keep suppressed), full mailbox (a soft failure that may recover, a candidate for reinstatement), or genuine spam complaint. For each address it writes back a keep or reinstate recommendation plus a one line reason, and those land back in the table as a recommendation column with the category, so the person can review them and bulk apply the safe ones in one click. Persist the recommendations so they are still there when the app is reopened, and show when the last triage run happened and over which filter.

One hard rule: spam complaints are recommendation only and must never be included in a bulk lift. Reinstating someone who pressed the spam button is a real deliverability risk, so exclude complaint rows from bulk apply entirely, show them with a visible warning in the table, and require the person to lift one deliberately from its own row if they really mean to. The agent should say this explicitly in its reasoning for complaint rows rather than silently skipping them, so the person understands why those addresses were left alone.

Also show progress while the triage agent is running, since it may cover hundreds of addresses, and keep the rest of the table usable while it works. Default the view to the last 30 days across all domains and all suppression types, which is the state a weekly hygiene review wants to start from.