What is the Anything API?

What is the Anything API?

The Anything API is the pattern of taking a browser-based workflow — anything you'd normally do by clicking through a website — and exposing it as a stable, versioned HTTP endpoint that other systems can call. The name captures the promise: if a human can do it in a browser, you should be able to wrap it in an API.

It's the natural extension of two ideas: browser agents made it possible to drive a UI through natural language, and workflow-to-API conversion packaged that capability so it could be called from any backend.

The problem the Anything API solves

Most useful business actions today happen on websites that don't expose APIs. You have to log into a supplier portal to download invoices. You have to use an internal HR tool to file expenses. You have to click through a dashboard to export a report. Every team accumulates a long tail of these "no-API" workflows.

The traditional fix was to assign an engineer to write a bespoke Playwright script for each one. That works for a couple of workflows; it breaks at scale because:

• Each script is hand-coded, hard-coded selectors that break when the UI changes.
• Each script needs deployment, scheduling, retries, and monitoring — a small piece of infrastructure on its own.
• Non-engineers can't extend or modify them. Every change is a ticket.

The Anything API collapses this stack into a single primitive: define the workflow in natural language or by demonstration, and Notte handles everything else — the browser, the retry logic, the scheduling, the credentials, the API surface. From the rest of your codebase, it just looks like a function call.

How the Anything API works

There are three steps from a UI-only workflow to a callable API:

1. Define the workflow. Either write a natural-language task ("log into Acme, navigate to invoices, download all PDFs from the last 30 days, return them as a list") or record a demonstration by clicking through the workflow once.
2. Schema the input and output. Specify what parameters the workflow takes (date range, account ID) and what shape the result takes (a list of file URLs, a structured JSON object). The schema is what gives the endpoint its API surface.
3. Deploy. The workflow is published as an HTTP endpoint. Calling it spins up a fresh cloud browser session, runs the agent against the live site, structures the output to your schema, and returns.

A minimal Notte example:

Under the hood, Anything API endpoints are deployed as Notte Functions — .py files with a run() handler that take typed parameters:

# acme_invoices.py — your handler
from notte_sdk import NotteClient

client = NotteClient()

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

# deploy.py — register the handler as a callable Function
from notte_sdk import NotteClient

client = NotteClient()

function = client.Function(
    path="acme_invoices.py",
    name="acme-invoices",
    description="List the last 30 days of invoices from the Acme portal.",
)
print(f"Function deployed: {function.function_id}")

# Call it like any other API.
result = function.run(account_id="acct_123")

Behind the scenes:

• A fresh, isolated cloud browser session boots for each call.
• The digital identity's credential vault injects the password without ever passing it through the LLM context.
• The agent runs the observe-think-act loop until it has the data.
• The output is validated against the schema before being returned. Hallucinations get caught at the schema layer.
• The full session — screenshots, action log, LLM trace — is captured for debugging.

Key capabilities

The point isn't that bespoke scripts are wrong — they're sometimes the right tool. The point is that the marginal cost of an additional workflow drops to near-zero with the Anything API pattern.

Common use cases

The Anything API tends to land in five categories:

1. Internal automations. Teams turning recurring "log into X, do Y, paste into Z" tasks into endpoints other systems call.
2. Integration glue. Bridging two SaaS tools that don't talk to each other, where one or both has no public API.
3. AI agent tool calls. A consumer-facing AI assistant that needs to take real action — book, pay, apply — invokes the relevant Anything API endpoint.
4. Data extraction at scale. Pulling structured data from authenticated dashboards on a scheduled cron.
5. Embedded workflows in products. SaaS products exposing third-party-site automations to their own customers (e.g., a billing tool that pulls invoices from suppliers on the customer's behalf).

When to use the Anything API

Reach for the Anything API when:

• A workflow has to run repeatedly and reliably.
• The target site has no usable public API.
• Multiple systems or teammates need to call the same workflow.
• You want the workflow to be callable from places where running a browser yourself would be painful (a Lambda, a worker, a chat agent).

Don't reach for it when:

• The site has a clean public API — call that directly. The Anything API adds latency and cost compared to a real REST call.
• The workflow is one-off (run it interactively from a notebook instead).
• The workflow has hard real-time constraints that an LLM-driven agent can't meet.

Key takeaways

• The Anything API is the pattern of wrapping a UI-only workflow as a stable HTTP endpoint, complete with schema, authentication, scheduling, and retries.
• It collapses the bespoke-script stack — selectors, deployment, monitoring, credential handling — into one primitive.
• Inputs and outputs are typed; the schema acts as a guard against agent hallucinations.
• It's the right shape when the work is repeatable, the target has no API, and other systems need to call it.
• Once the workflow exists as an endpoint, it composes with the rest of your stack the same way any other API does.

If you're starting out, the next reads are workflow-to-API conversion for more depth on the underlying mechanics, and scheduled browser tasks for how to run these on a cron.