Supergood

About Supergood

Supergood is an integration platform that generates REST APIs for software that never shipped one. A user records a workflow once in a cloud-hosted Chrome session, and an AI coding agent reads back the network calls, cross-references the site's own JavaScript bundles and embedded page state, and writes a working integration, an OpenAPI spec and a customer-facing guide. No browser is involved at runtime: the generated endpoint calls the vendor directly over HTTP.

Every generated integration lands on the same contract, POST /integrations/{integration_slug}/{mode}, where mode is either sync, which waits for the result, or async, which acknowledges immediately and delivers the payload to a callback URL. Whatever the vendor's underlying API looks like, the calling convention does not change. The pitch is narrower than the category Supergood is usually filed under. Where browser-automation and scraping platforms operate a headless or extension-hosted browser on every call, Supergood targets vendor-locked software specifically, the systems that will never get an official developer API because they are old, because no vendor will prioritise a developer roadmap for them, or because the customer does not own the relationship.

Supergood is built for teams wrapping a short list of stubborn vendors rather than for scraping at marketplace scale: every integration passes through a recorded session and a human-reviewed diff before it ships. As of September 2026 the company also runs two content properties, docs.supergood.ai, which hosts speculative reference documentation for platforms with no public API, and supergood.ai/api-report-card, which grades 1,465 platforms across six axes (Existence, Access, Coverage, Auth, Docs and DX, Stability) plus an MCP-readiness tag. Generated integrations also ship a standalone skill file, positioning them as tools an agent can call rather than as REST endpoints that happen to also work for agents.

How the generation works

The build loop has three steps. A Service Account provisions a synthetic identity, with a generated email address and phone number, so the integration can absorb MFA codes and vendor CAPTCHAs on its own rather than borrowing a real employee's login. A recording captures a person or an agent driving a cloud-hosted Chrome session, streamed over VNC with a REC indicator and a live recorded-calls counter, through the workflow to be automated. Generation then hands that recording to an AI coding agent, which writes the integration, the spec, the guide and the skill file, all reviewed through a diff interface modelled on a GitHub pull request before anything ships.

The generation step is where the product separates from browser automation. The agent treats the recording, the rendered HTML and the site's compiled JavaScript bundles as three separate sources and cross-checks them against each other, hunting for two things beyond the calls it actually watched happen: framework hydration payloads, the JSON snapshot that modern front-end frameworks embed in the page so the client app can render without a second round trip, and enum or mapping tables sitting in the bundle that nothing in the recording ever exercised. That is the mechanism behind turning a handful of recorded clicks into a full schema. The agent is not extrapolating from examples; it is reading the site's own source of truth for its data model.

The generation sessions AutomationAtlas observed in September 2026 ran on Claude Opus 5.

What the field test found

AutomationAtlas built three integrations end to end, against deliberately different targets. The first was a sanity check against the form-auth demo on a public test site, a deliberately trivial login flow with published test credentials, chosen so that no real vendor's terms were at stake. The generated code recovered the undocumented POST /authenticate endpoint, which the page itself never exposes (it shows only /login and /secure), got the redirect codes right at 303 on submit and 302 on logout, and identified that the whole session lives in one rotating rack.session cookie. A self-run replay against the recording reported 5 of 5 success-path flows and 3 of 3 invalid-credential flows matching.

The real target was a Polish government body's public listing of court-ordered auctions. It is government-adjacent, with no login and no official API: the kind of institutional source that will never ship a developer API but that proptech, deal-sourcing and local-journalism tooling would like to poll on a schedule. Its robots.txt allows the public search and listing paths and disallows only logged-in account routes.

The recording covered exactly two searches, both in the real-estate section, both in one province: houses, then land. The movables tab was never touched. From that, the agent recovered the portal's entire taxonomy out of its compiled Nuxt bundles and server-rendered page state: two main categories, 8 real-estate and 17 movable sub-category codes with their Polish labels, and 16 provinces plus an all-provinces sentinel, folded into one validated mainCategory / subCategory / province schema. It also excluded a second recorded call carrying limit: 0, which was not a listing search at all but a separate facet-count request.

Two live calls settled it. The demonstrated query, houses in that province, returned 200 OK with 33 total matches and 20 rows, matching the live site exactly. The undemonstrated one, computer and electronics listings with no province filter, returned 200 OK with 64 total matches nationwide. Both were real HTTP calls made from a fresh sandbox rather than from the recording browser, and both came back clean on the first attempt. The second is the result that matters: the electronics search had been awkward to demonstrate by hand through a remote browser, and demonstrating it turned out to be unnecessary, because the agent had already found the category by reading the portal's own code.

The harder request, and the bug the platform caught

Two working integrations is the easy case: record a search, generalise a search. AutomationAtlas went back to the auction integration and asked for something structurally different, not another protocol translation but a second capability requiring orchestration on top of the first. A compareProvinces function walks the existing search endpoint's pagination twice, once per province, aggregates opening-price and estimated-value statistics for each, and computes the percentage difference between them.

The first attempt, appending a second independent code block for the new function, silently broke the original search. Supergood integrations can carry multiple code blocks, all of which execute, but only the last block's output becomes the call result, with no merge and no fallback. Nothing in the visible documentation says so. The agent established it empirically, repurposing Supergood's replay-against-recording sandbox, a network-denied dry run meant for regression testing, as a probe. Three throwaway replay calls established, in order, that both blocks run, that only the last one's output ships, and that a shared context object survives between them. The agent then redesigned around an operation field defaulting to search, leaving existing callers unaffected, gating both blocks so that exactly one does real work per call.

Mid-fix it left a debug probe at the top of the new block, logging the input and returning early, which made the entire comparison implementation unreachable dead code. AutomationAtlas did not catch that. Supergood's automated code-review step did, blocking the revision before it reached the human diff and naming the exact defect: the shipped block returned internal harness key names instead of the documented comparison result, and the real code path was never exercised in production. The agent changed method rather than shipping the debug code, moving its diagnostics into a disposable replay script, and re-verified the search path, the comparison path and the error path as three separate checks. A gate that blocks a bad revision rather than merely flagging it is the right shape for the problem, even though it exists only because the same system produced the bug.

The live cross-province run followed: two provinces, houses, capped at two pages per province. Four real HTTP calls, all 200s, 9.7 seconds of wall time, sampling 33 of 33 listings on one side and 40 of 82 on the other, with the partial sample correctly flagged as partial. The capability did what was asked of it. It paged through both provinces, aggregated an opening-price and an estimated-value average for each, and returned a comparison object carrying the percentage difference between the two, signed in the correct direction. Recomputing those percentages by hand from the averages the tool itself reported matched to two decimal places, which is the check that separates arithmetic from narration.

The old-technology case

Every target so far had one thing in common that the field test did not notice until it went looking for the opposite. The demo site and the auction portal are both modern enough to make XHR calls, and the second embeds a full client-side data model the agent could simply go and read. That is a weak way to probe a product pitched at vendor-locked software. So a fourth integration went after the opposite of a Nuxt single-page app: a full-postback site with no XHR traffic and nothing embedded to read.

The target was a public parcel-records portal that one vendor licenses to local government across the United States. The vendor's own site listed more than a thousand towns, cities and counties across nine states in September 2026, each running the same template at its own path, and AutomationAtlas used one county's instance. It is classic ASP.NET WebForms, with the hidden viewstate and event-validation fields that framework posts back on every request, a self-posting search form, and control names of roughly 2008 vintage. There is no login and no CAPTCHA, and robots.txt does not block the paths the test needed. Structurally it is the same vendor-lock story as the auction portal, one vendor templated across a thousand small-government clients who will individually never get a bespoke API, on the old-technology side of the divide rather than the modern one.

The recording covered two operations, kept deliberately narrow: searching by address, and opening that result's parcel detail page. Both are full-page navigations, a GET of the form, a POST back, a GET of the results and a GET of the detail page, without a single XHR call anywhere in the flow. That shape exposed a recorder limitation the first three tests had no way to surface. Supergood's recorder is built around the network-call model that fitted them, and it captured this flow's form POSTs reliably but not the top-level document GETs around them, which is the page-to-page navigation itself. The agent's generated notes said so directly, flagging that the GET-driven steps were inferred from the recording and the rendered HTML rather than confirmed by replay, since replay works against captured network calls and a full document navigation is not one.

It also produced a real bug, in exactly the mechanism the earlier tests could only describe in the abstract. With no embedded JSON state to cross-reference, because this target has none, the agent fell back to parsing the rendered detail page's HTML table for building and area data. One of the source table headers is authored with a line break inside it, Gross on one line and Area on the next, and a naive text extraction concatenates across it with no space to produce a single token. That broke the header-to-field mapping for the column, silently dropping or mis-assigning the gross-area, living-area and per-building sub-area totals in the generated schema. AutomationAtlas did not spot it by inspection. The agent caught it itself, through the same replay-against-recording self-test it had used on the auction portal, and shipped the fix with the mapping corrected.

Two live calls checked the result. The address search returned 200 OK with the owner name and parcel id matching the live site exactly, and the GET-then-POST-then-GET chain that the agent's notes had marked as inferred from the recording worked on the first live attempt. The parcel lookup returned 200 OK from a single real request in 458 milliseconds, and its response was read specifically to check the header-parsing fix under live conditions rather than on the replay's word. The first sub-area reported a gross area and a living area of 1,352 square feet each, and the building's aggregated totals reported 3,004 and 1,936, both fields present, correctly split and matching the live site's own sketch and area data.

Two targets in, that reads as a loop rather than a lucky catch. The agent writes, tests its own output against the recording, a separate review step reads the result, and a failure sends it back to change method rather than to patch the symptom. Both times it caught a defect before AutomationAtlas saw one, and both defects were of a kind a human reviewer would plausibly have signed off. Every repair observed here happened while the integration was being built, which is the stage this field test covers.

Where it shows its seams

The technology is further along than the product wrapped around it. List views do not update optimistically: twice, a success toast was not matched by the list showing the new item until the page was hard-reloaded. The manual test-input editor is a Monaco-style JSON box with bracket auto-pairing, and it is unforgiving of anything but careful typing. Hand-editing a payload corrupted it repeatedly, and reliable results came only from asking the in-panel agent to draft the JSON instead. A tool this central to the test-your-integration loop deserves a plainer text input or a form-based builder.

The Anomalies dashboard and the API Logs view are both scoped to deployed traffic rather than to the sandbox test runs made while building. That is defensible on reflection, but the empty state, which reports no runs in this period immediately after two runs that very much happened, does not explain itself, and the dashboard took close to ten seconds to leave a bare loading spinner.

Supergood publishes no price list as of September 2026, so the cost comparison rests on structure: a generated call is one HTTP request, where the DOM-scraping equivalent rents a browser for the length of the job. A published industry estimate put list pricing for hosted browser automation at roughly $0.12 to $0.24 a call as of September 2026, on the assumption of one session per call, and put the realistic figure nearer $1 to $1.50 once a login, a navigation, a few clicks, a form submit and often a model round-trip or a CAPTCHA are counted. Neither figure is Supergood's; both price the browser session that a direct HTTP request avoids, so they bound what a Supergood call replaces rather than what it costs.

One inaccuracy recurred and is worth writing down. The agent's generated notes claimed twice, in two separate sessions, that the integration had never run against the live site because execution was disabled, and both times the live test button then ran against the live site successfully. Its narration is a pitch. The replay logs, the live test output and the code-review gate underneath that narration are the spec, and those are what to judge it on.

Scope of the field test

Judged against Supergood's own narrower claim rather than the broader category it gets filed under, the field test covered both sides of the age divide: modern sites that make XHR calls and a full-postback ASP.NET WebForms site with none.

The parcel portal was the old-technology test. It showed that the mechanism does not fall over on a site with no XHR traffic at all the way a purely network-layer tool would have to. It shifts to parsing rendered markup when that is the only source of truth available, closer to traditional DOM scraping than to what happened on the auction portal, and its own self-testing caught the resulting fragility before a human did. The scope was two operations on one county's instance of one vendor's template. The agent's own notes expect the same integration to work against any of the vendor's thousand-plus municipal clients on little more than a hostname change. That expectation rests on the shared template, which every instance runs at its own path; the field test exercised one instance.

The other half of vendor-locked is authentication rather than age: the enterprise systems that gate themselves behind SSO, device-bound MFA and bot fingerprinting precisely to keep tools like this out. Supergood's answer is the Service Account layer, which provisions a synthetic identity with a generated email address and phone number so an integration can absorb MFA codes and CAPTCHAs itself. In this field test the Service Account layer worked once, against a deliberately trivial form-auth demo login with published test credentials.

Who it is for

Supergood is a strong fit for a team that needs to wrap a short, specific list of stubborn no-API vendors or public data portals and wants working code, with its own tests and documentation, out the other end inside an afternoon. It is less obviously a fit as a one-tool-for-hundreds-of-sites platform, since every integration still passes through a recording and a human-reviewed diff rather than running unattended.

There is a broader reading of the product that the category label hides. The comparison capability was not a protocol translation at all. It walked pagination twice, aggregated statistics and computed a difference, which is ordinary automation work rather than API generation. For a company with a process worth automating and nobody free to write it, that changes what Supergood is for: somebody who knows the workflow records it, and the agent works out both the calls and the arithmetic in between. That is a different purchase from an API for a vendor who will never ship one, and on this evidence it is within range. It is also the part with the least protection, since a recording is a demonstration of intent rather than a specification, and everything inferred between the calls stays inference until somebody checks it.

Because the runtime cost is a REST call rather than a headless browser session, the approach avoids the per-call browser compute a DOM-scraping equivalent pays, which matters when the job is checking forty auction categories every morning rather than fetching one page once. The uniform contract gives a team running several Supergood integrations a single client surface: the same auth shape, the same pagination idiom, the same async and callback pattern. Two of the three targets in this test were public-sector portals rather than enterprise software that forgot to build an API, and whether that is also the product's largest market is not something a field test can settle. What it did cover is the long tail of government, municipal, court and registry portals that will never ship an API, and that are otherwise reached only by brittle, DOM-coupled scrapers that break on every redesign. The parcel portal is the sharpest version of that. One vendor's template runs unchanged across every one of those instances, so a single working integration is a candidate key to all of them, on the evidence of the shared template.

The judgement the tool does not make is the legal and ethical one. It removes essentially all of the technical friction between finding a site with useful data and running a scheduled job that pulls it, which is why a robots.txt and terms-of-service check has to become a permanent habit rather than an optional step. Supergood makes the endpoint trivial to build. It does not make it anyone's right to call it.

Editor's Note: Our first three integrations ran against modern sites, where a front end gives up its data model almost by accident, so the fourth went after a roughly 2008-vintage ASP.NET parcel portal with no XHR traffic and nothing embedded to read. The mechanism held. The fragility we had only described in the abstract showed up as a real bug, a line break inside a table header silently breaking a field mapping, and Supergood's own self-check caught it before we did. The fix then survived a live run, with the building's gross and living area totals, 3,004 and 1,936 square feet, correctly split and matching the live site's own area data. That is more convincing than a clean pass would have been. — Rafal Fila, ShadowGen