What is workflow-to-API conversion?

What is workflow-to-API conversion?

The first time you build a browser-driven workflow, it's a script. You run it from a notebook. It works. The second time anyone asks for it — your colleague, the next team, a customer — the friction starts. Now it has to be deployable, callable from somewhere other than your laptop, with arguments validated, with errors handled, with a result shape someone else can rely on. That's the gap workflow-to-API conversion closes: take the working script, give it a stable interface, deploy it, retry it, schedule it, monitor it. The work nobody wants to do, automated.

What "an API" actually requires beyond the script

Five properties separate a runnable script from a production-grade API:

1. Typed input/output. A schema for what arguments the workflow takes (account_id: str, date_range: tuple[date, date]) and what it returns. Without this, callers don't know how to call it.
2. Versioning. When the workflow changes, callers shouldn't break. Either a new endpoint version, or a backward-compatible additive change with a deprecation path.
3. Retry and durability. If the browser session fails on step 7 of 12, the API should retry from the right point — not from scratch — and surface a clean error if recovery isn't possible. See durable browser execution.
4. Authentication and rate limiting. Who can call this? How often? What credentials does the agent itself use during the run (vault attached, identity selected)?
5. Observability per call. Every invocation produces a session recording, a structured log of actions, a verifiable success/failure verdict — so failures are debuggable and successes are trustworthy.

A script becomes an API once all five exist. The intermediate shape — "deployed script with a flag-shaped CLI" — is the half-built version most teams accidentally end up with.

The conversion pattern

Three shapes of starting workflow, each with a slightly different conversion path:

• Recorded agent run. A browser session captured by Notte's recorder, replayable. Conversion = parameterize the inputs (URL, search query, account ID), bind a schema to the output, deploy. Lowest-effort path.
• Hand-written agent script. A Python file using client.Agent(...).run(task=...). Conversion = wrap in a run(...) handler, define I/O schemas, deploy as a Notte Function.
• Hand-written Playwright script with hard-coded selectors. Convert by re-implementing as an agent task (more robust to UI churn) or by wrapping the existing script as a Function (faster, brittler).

The recorded-run path is the fastest. The hand-written agent path is the most flexible. The hand-written Playwright path is rare in 2026 — most teams converting at this point have already moved to agent-based workflows.

What this looks like with the Notte SDK

# acme_invoices.py — the workflow as a Function handler
from notte_sdk import NotteClient

client = NotteClient()

def run(account_id: str, days_back: int = 30):
    with client.Session(proxies=True) as session:
        agent = client.Agent(session=session, max_steps=15)
        return agent.run(
            task=f"Log into the Acme portal as {account_id} and "
                 f"list invoices from the last {days_back} days.",
        ).output

# deploy.py — register and call the Function
from notte_sdk import NotteClient

client = NotteClient()

function = client.Function(
    path="acme_invoices.py",
    name="acme-invoices",
    description="List recent invoices from the Acme supplier portal.",
)

# Now it's an HTTP endpoint other systems can call.
result = function.run(account_id="acct_123", days_back=30)

The client.Function(...) call is the literal conversion: workflow on the left, callable API on the right. From here it's deployable, callable from any backend, schedulable on a cron, retried on failure.

Conversion-to-API vs. the Anything API

Easy to conflate. The clean split:

• The Anything API is the user-facing concept — "any browser workflow becomes an API." A category and a product surface (anything.notte.cc).
• Workflow-to-API conversion is the technique — the actual mechanics of taking a workflow and producing a callable endpoint. The Anything API uses this technique; so do hand-rolled internal solutions; so do other vendors.

Same relationship as schema-based extraction (technique) and page-to-JSON extraction (product) in the data cluster.

Common pitfalls

• Skipping the schema. Untyped APIs that accept and return free-form JSON are technically APIs but practically a maintenance trap. Pin the input and output shapes upfront.
• Treating one-shot scripts as production. "It works on my machine" deploys to production "it works some of the time." Add retries, verification, observability before shipping.
• Hard-coded credentials in the workflow. The point of the API is callability — including by other systems with their own credentials. Use credential vaulting or per-request credential parameters.
• No verifier. A converted workflow that returns "success" without a verifier is just relaying the agent's own self-assessment.

Key takeaways

• Workflow-to-API conversion is the work of taking a one-off browser workflow and shipping it as a stable, typed, retried, observable HTTP endpoint.
• Five properties separate a script from an API: typed I/O, versioning, retry/durability, auth/rate limits, per-call observability.
• The Notte path is client.Function(path=..., name=...) — the workflow code on the left, a callable API on the right.
• Don't confuse with the Anything API: same idea at different levels — Anything API is the product, workflow-to-API conversion is the technique.