# An inspector for marketer-owned API connections
> A UI for marketers managing beacon hardware and data-partner connections — surfacing provider errors and job-level failures without paging an engineer.
- Author: Alejandro Haydar
- Published: 2018-09-15
- Category: Product Design
- Canonical: https://alejandroastroport.netlify.app/showcases/swirl-api-connector-management/
---
In 2018, Postman was a tool engineers used to inspect APIs. There was no equivalent for the marketer who actually owned the connection — and the connections were the lifeblood of every campaign.
Swirl's platform ran on a stack of live data pipelines: beacon hardware vendors (Cisco Meraki, Google Beacon Platform), DMPs (Oracle BlueKai, Adobe Audience Manager), email and CRM platforms (Oracle Responsys), analytics tools (Adobe Analytics), and data co-ops (LiveRamp, Catalina). When one broke at 3am — an expired credential, a vendor-side outage, a misconfigured endpoint — the marketing team only found out when a campaign silently stopped firing. By then they'd already filed a ticket and pinged engineering.
The fix wasn't to teach marketers how to *fix* integrations. It was to let them *see* what was broken.
### The setup
Every provider was a live data pipeline — POST URLs, secrets, validators, RSSI thresholds, captive portal config. Each one ran scheduled data-extract jobs against those settings. When something went wrong, the platform logged it. The logs went to engineering. The marketer saw an opaque "campaign paused" state with no way to triage. Half the engineering tickets that quarter were provider noise: vendor outages, expired tokens, and rate limits that didn't need an engineer to identify — only to acknowledge.
### The decision
The line was deliberate: **diagnose, don't fix.** The marketer wouldn't get credential entry or raw API tooling — those involve security boundaries that belong with engineering. But they would get a provider list, a detail panel with the current config, and an Associated Jobs table showing every data-extract run with its status.
Enough to file a useful ticket. Enough to know whether the issue was on the vendor's side or Swirl's, before paging anyone.
The risk was the surface drifting toward an ops dashboard — and reading like one. The discipline was keeping the marketer's vocabulary on top: *provider* not *endpoint*, *PROVIDER ERROR* not *HTTP 401*, job run timestamps over log levels. The engineering-grade detail was visible, but framed around the question a marketer actually asks: *is this connection working right now?*
Provider error state. The PROVIDER ERROR badge appears immediately — no digging through logs. Below it, the Associated Jobs table shows every data-extract run with its status and timestamp. A marketer could see at a glance that the Meraki connection had been failing since a specific date and hand that directly to engineering.
### What shipped
Nine provider integrations with a self-serve picker. Adding a new connection meant choosing from the grid, filling in the settings, and letting the platform validate. No engineering ticket to wire up a new data source.
New Provider picker. Nine integrations across beacon hardware, DMPs, email platforms, and data co-ops — the full stack a retail marketer needed to run a synchronized in-store campaign. Selecting one walked through the settings; the platform handled the rest.
### What I'd take with me
The instinct in 2018 was to keep provider tooling behind an engineer. The cost of that instinct was a marketing team that filed tickets blind and an engineering team that spent half a week a quarter triaging provider noise that hadn't actually broken on Swirl's end.
Building this for the marketer didn't mean handing them root. It meant giving them *visibility*. The Postman-for-engineers pattern was already a couple of years from going mainstream; the equivalent for the marketer who actually owned the pipeline was still missing. We built it.
