Callables vs Zapier: when your automation is really code

Zapier is the default answer to "can we automate this?", and for good reason. It connects more than 9,000 apps, and anyone on the team can build a Zap without writing code. If the job is "when a form is submitted, add a row to a sheet and post in Slack", Zapier is hard to beat.

Some automations aren't that shape, though. They're a few hundred lines of Python with real logic in them: pulling data from two APIs, matching records, calculating something, and writing the results back. That's where Callables fits.

Different starting points

Zapier starts from apps. You pick a trigger and a chain of actions from its catalog, and fill in fields. When the catalog doesn't cover something, you can add a Code step, a small Python or JavaScript snippet inside the Zap.

Callables starts from code. You write a normal Python function in your own repo, with your own editor and AI agent, and add @deploy. Callables turns it into a form your team can run, with schedules and a history of every run:

from callables import deploy


@deploy(
    title="Reconcile invoices",
    secrets=["STRIPE_KEY", "QUICKBOOKS_TOKEN"],
)
def reconcile(month: str = "2026-10") -> list[dict]:
    """Finds payments in Stripe with no matching invoice in QuickBooks."""
    ...

Anything Python can do, the function can do: any package from PyPI, your own modules, and as much logic as the job needs.

Where code steps get tight

Zapier's Code steps work well for small transformations. They're designed as one step in a Zap, so they have limits that bigger jobs run into: a runtime cap per step (1 second on the free plan and 30 seconds on Pro and Team, with longer runtimes billed extra), and the code lives inside the Zap rather than in your repo, so it isn't versioned, reviewed or tested with the rest of your code.

On Callables, the whole automation is your code. Runs can take minutes, not seconds, with up to several gigabytes of memory. Changes go through the same pull requests as everything else, and every push to your branch deploys.

People, not just triggers

Most Zaps run on their own when a trigger fires. Many internal automations need a person to start them: someone in ops refunding an order, or finance running month-end with a date they choose.

Callables gives every function a form built from its inputs: dropdowns for fixed choices, date pickers, checkboxes and file uploads. You decide who can run each one, and every run keeps its inputs, logs and result, so anyone can check what happened.

Pricing

Zapier charges by task: each successful action step in a Zap uses one. Pro starts at $19.99 a month (billed annually) for 750 tasks, and Team at $69 for 2,000. A Zap with four actions that runs 500 times a month uses 2,000 tasks.

Callables charges for the compute your runs use, not for steps. Pro is $20 a month per team with $20 of usage included and no per-seat price, and Hobby is $5 a month. A function with 20 steps inside it costs the same as one with two, if it runs for the same time. See pricing.

At a glance

Coming soon: webhooks and the API

Today, Callables functions run from their form or on a schedule. Two more ways to start them are on the way:

• Webhooks. Each function will get a URL other systems can call, so a new signup, a payment or a GitHub event can run it automatically.
• The API. You'll be able to run functions from your own code and scripts, and read their results.

That also makes Callables and Zapier work well together: let a Zap catch the event in one of its 9,000 apps, then call a Callables function to do the heavy lifting in Python.

Which one to use

Use Zapier when the job is connecting apps with little logic in between, and the people building it don't write code.

Use Callables when the automation is really a program: it has logic worth testing, needs packages or more than a few seconds to run, or needs a teammate to start it with the right inputs. Write the function, push it, and your team has a tool.