Turn any website into an API

On authorization. Writ runs on your own accounts, with your own credentials and data, on sites you are authorized to use.

APIs cover a thin slice of the software world. The rest (internal admin panels, supplier portals, government filing systems, legacy tools, anything behind a login) has no API and never will. The standard answers are brittle scripts that break on the next UI change, or heavyweight RPA suites built for one-off tasks. There is a simpler path: capture the workflow once, and turn it into something your software can call.

The problem: most of the web has no API

Think about the last time you needed data out of a vendor portal, or needed to file a form in a system that only exists as a web app. There was no documented endpoint, no SDK, no webhook. A person could do the task in a browser in two minutes. Software could not, because the work lived behind authentication and a submit button.

Writ closes that gap. You record a real browser workflow, or describe the goal and let AI build it, and Writ exposes it as a stable, callable endpoint at /v1/{slug}/{path} and as an MCP tool. It runs the way a person would, on your own account and with your own credentials, so it reaches the authenticated, dynamic web that read-only crawlers cannot.

Three ways to build a workflow

There are three build paths, and you can mix them in a single workflow:

Record. Open the recorder, do the task in a real browser, and Writ captures each step (clicks, fills, navigation, extraction) as a replayable recipe.
Describe. Tell AI the goal in plain language and let it build and drive the workflow, deriving the steps from the live page.
Discover. Let Writ watch the network while you use the site and surface the underlying calls, so a noisy UI flow becomes a clean request.

The result is a workflow with typed inputs and a structured output. From there, publishing is a single action.

Publish it as a REST endpoint

Publishing turns the workflow into a managed endpoint with its own slug. You call it with a wt_ API key, pass inputs as JSON, and get structured JSON back.

quickstart.sh · cURL

curl https://api.usewrit.app/v1/portal-export/run \
  -H "Authorization: Bearer wt_8f3a…" \
  -H "Content-Type: application/json" \
  -d '{ "account_id": "AC-19284", "since": "2026-06-01" }'

response.json · json

{
  "status": "succeeded",
  "run_id": "run_7d1c…",
  "data": {
    "invoices": [
      { "id": "INV-5521", "amount": 1840.00, "due": "2026-07-15" },
      { "id": "INV-5522", "amount":  620.50, "due": "2026-07-18" }
    ]
  }
}

That is the whole contract: a slug, a key, JSON in, JSON out. Your software no longer needs to know that the data lives behind a login and three menu clicks.

Expose it as an MCP tool

The same workflow can be published as a Model Context Protocol tool, so an AI agent can call it directly. Point your MCP client at the Writ server and the workflow shows up as a typed tool the agent can invoke, with the same authorization and spend controls as the REST path.

mcp-client config · json

{
  "mcpServers": {
    "writ": {
      "url": "https://api.usewrit.app/mcp",
      "headers": { "Authorization": "Bearer wt_8f3a…" }
    }
  }
}

Now Claude, Cursor, or any MCP-capable agent has a tool for a site that never shipped an API. The agent does not see your credentials. It calls the tool, and Writ runs the workflow on your account.

Where it runs (and what it costs)

A workflow can run two ways. On a BYO agent (the Writ agent on your own machine) there is no compute charge on any plan, and it can reach localhost, your LAN, and VPN-only systems the cloud cannot see. In the managed cloud, runs are metered by actual running time (about $0.12 per browser-hour) from your plan’s included usage, and from a prepaid top-up past it.

Free on your own hardware. Run on a BYO agent and you pay nothing for compute. The Free tier is still metered by a monthly execution allowance; paid plans lift that cap so local runs are effectively unlimited. Hard spend caps are on by default for cloud runs.

Surviving UI changes

The reason scripts rot is that they pin to fragile selectors. Writ recordings use resilient selectors with stability helpers, and AI navigation re-derives the path when the layout moves. The practical pattern: record the stable backbone of a flow, and let AI handle the parts that change. The endpoint stays the same even when the site underneath does not.

That is the whole idea: a durable interface in front of an interface that was never meant to be one. Read the full fundamentals guide for a step-by-step walkthrough.

Try it on a real site

Record a workflow or describe a goal, then call it as REST and MCP.

Get started See managed endpoints

Common questions

Is this allowed?

Writ automates work a person could do by hand in a browser, on sites you are authorized to use, with your own credentials. It does not break into anything, and your credentials never leave your control. Respect each target site's terms of service and rate limits.

Does the endpoint break when the site changes?

Recorded recipes use resilient selectors with stability helpers, and AI navigation re-derives the path when the UI moves. You can also mix both - record the stable parts and let AI handle the volatile ones.

What does it cost to run?

Runs on your own machine carry no compute charge. Managed-cloud runs are metered by actual running time (about $0.12 per browser-hour) against your plan’s included usage, then against a prepaid balance at the same rate, with hard spend caps on by default.

How to turn any website into an API (without waiting for the vendor to build one)