Every scraping API in the market - Firecrawl, ScrapingBee, Bright Data, Apify, Zyte - shares the same architecture under different pricing and branding: fetch a URL, render the page, extract the HTML. That architecture has a hard ceiling. It can only see what an anonymous visitor sees.
No order histories. No seller dashboards. No B2B portal pricing. No personalized inventory feeds. No member-only listings.
The industry calls this "web data." It's more accurately "logged-out data."
The data that matters was never on the public page
When businesses talk about needing web data, they rarely mean public pages. They mean their own data inside platforms that didn't build an export:
- Their order history in a marketplace with no API
- Their B2B supplier portal with custom pricing their competitors can't see
- Their seller dashboard with no CSV download
- Their SaaS platform data the vendor's API tier doesn't expose
Public-page scraping answers "what does the internet say?" Account-scoped access answers "what does my data say inside this platform?"
Most SaaS and marketplace platforms have no public API, or a crippled one that doesn't expose the same data their own frontend does. The data exists - it's right there in the dashboard - but the platform never built a way to get it out programmatically.
Why existing scrapers can't just add a login feature
The straightforward fix - "just log in first, then scrape" - doesn't work at production scale. The entire scraping stack is built around stateless page-fetching: URL in, HTML out. Sessions break that model.
Authenticated sessions require state management across requests, expiry handling and re-authentication, per-account behavior differences, and request consistency across a sequence of calls. Bolting login onto a stateless page renderer produces a fragile browser puppet, not a product. Cookie-jar injection works at n=1; at production volume, you're managing session lifecycle, handling expiry mid-workflow, recovering from auth challenges, and rebuilding from scratch every time the target site redesigns its login flow.
The deeper reframe: pages are a rendering artifact
There's a more fundamental issue with HTML scraping that isn't obvious until you open DevTools.
Modern websites aren't made of pages. They're made of API calls. Open the Network tab on any major site and watch what happens: the page you see is assembled from a sequence of structured JSON responses the browser fetches and paints onto the DOM.
The HTML is a rendering of the data, not the data itself. Scraping HTML is scraping a screenshot of the truth.
Everything a page shows - search results, prices, order rows, inventory counts - arrived as a structured JSON payload before the browser painted it. That payload is available directly, without the browser.
Browser layer vs. network layer
This leads to two fundamentally different architectures:
Browser-layer scraping (how every scraping API works today): load the full page, wait for JavaScript to execute, parse the DOM, extract what you need, hope the CSS class names didn't change in the last deployment.
Network-layer access (Wire's model): identify the exact endpoints the site's own frontend calls, call them directly, receive the same structured JSON the frontend receives.
The practical differences at production scale:
- Speed: a single HTTP call vs. a full browser render. Orders of magnitude faster.
- Cost: no browser fleet burning CPU to paint pixels nobody looks at.
- Stability: sites redesign their UI constantly. Their internal API endpoints change far less often - their own apps depend on them. A selector breaks on every frontend deploy; the underlying data call typically doesn't.
- Fidelity: the JSON payload often contains more data than the page renders. Fields the UI drops on the floor are still in the response.
Wire's action model
Wire is built on this architecture, with one addition: it operates at the level of actions, not URLs.
A scraping API's unit of work is a page. Wire's unit of work is a named, typed operation against a platform: get_order_history, list_inventory, search_products. Structured input in, structured JSON out. Versioned. Documented. Priced per call.
What this produces is a public API for platforms that never shipped one. The platform doesn't need to build it - Wire builds it by identifying and wrapping the network calls the platform's own frontend already makes.
# Dispatch an action - search Amazon for a product
curl -X POST https://api.openwire.sh/v1/wire/task \
-H "X-API-Key: $ANAKIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{"action_id": "am_search_products", "params": {"query": "noise-cancelling headphones", "limit": 5}}'
# Response - poll the returned URL until status is completed
{
"status": "processing",
"job_id": "job_7f3d1a8c",
"poll_url": "https://api.openwire.sh/v1/wire/jobs/job_7f3d1a8c"
}
# Poll for result
curl https://api.openwire.sh/v1/wire/jobs/job_7f3d1a8c \
-H "X-API-Key: $ANAKIN_API_KEY"The result is structured JSON specific to the action - am_search_products returns typed product listings, get_order_history returns order rows. No HTML to parse. No selector to maintain.
The current catalog covers 967 sites with 5,261 actions across finance, marketplaces, research, shopping, travel, and 40+ other categories. (Anakin Wire catalog)
Authenticated identities: your data, now with an API
The unlock is the identity model.
Wire actions can run as an authenticated user. A customer connects their own account - their credentials, their session - and actions execute inside that session. Account-scoped data (order history, dashboard metrics, portal pricing, inventory feeds) becomes API-accessible for the first time.
Credentials are stored once as a named identity, AES-256 encrypted at rest, injected at runtime, and never returned by the API. The secret never crosses the API boundary after the initial save.
The key scope boundary: Wire reaches data you already have access to, but couldn't get programmatically. It doesn't reach data you don't have permission to access.
Wire does not collect, aggregate, or retain user data. When an action executes, it returns that user's own data to them. No personal information is stored by Wire as a result of running an action - credentials and retrieved data are used only to execute the action you requested, nothing else.
Write actions, not just read
Page scrapers are read-only by design. Wire's action model isn't.
Where relevant and available in the catalog, Wire actions support writes as well as reads. Submitting a form, updating a listing, triggering a workflow inside a platform - the same model, the same API call, the same identity system. AI agents don't just need to read the web; they need to use it.
Built for AI agents
AI agents are increasingly the primary consumers of API calls alongside traditional developer pipelines. Wire's action model is shaped for this: a discoverable catalog with self-describing schemas, structured JSON payloads without raw HTML, minimal round trips. An agent that knows which action to call executes it the same way it calls any tool.
Wire ships inside the Anakin MCP server. One install and an agent gets a wire_action tool that covers every site in the catalog - no SDK glue, no per-platform integration work. Compatible with Claude, Cursor, Cline, Windsurf, Zed, VS Code, and any client that speaks the Model Context Protocol.
Scraping APIs were built for ETL pipelines. Wire is built for agents.
On authorization and legal scope
Wire runs actions using the customer's own credentials, on the customer's own accounts, at the customer's explicit direction. The access model is user-authorized, not bulk or anonymous.
This puts Wire in the same category as other user-authorized access tools: email clients accessing a user's mailbox via IMAP, Open Banking platforms like Plaid accessing bank data via permissioned credentials, password managers interacting with sites on the user's behalf. The common thread: the user authorizes access to their own data - not a third party accessing data they have no relationship to.
Wire does not reach data that requires permissions the user doesn't hold. Scope is bounded by what the authenticated account can already see.
Wire does not collect, store, or resell any data it retrieves. This is both a design principle and a legal boundary.
Some flows genuinely need a browser: CAPTCHAs, certain multi-step auth challenges, pages that don't expose their data via background API calls. Wire has browser-based execution as a fallback for these cases. The network layer handles the vast majority of production workloads; the browser is the fallback, not the foundation.
Get started
At $0.001 per Wire call vs. $0.47 for a browser agent equivalent, the cost difference is 470x. (Anakin Wire) The catalog is public and searchable by site and action type. The Starter tier includes 300 credits at no cost - no card required.
For MCP workflows, the quickstart covers installation in one command.