Activepieces flow, built and verified by a coding agent

What this repo shows: a coding agent — Claude Code — installing Activepieces, building a working automation through its REST API, finding four real defects, fixing them, and then proving the automation works by running it and reading the results. No node was placed by hand in the flow builder. No step was declared finished on the strength of an exit code.

📖 Read the full development journey →

The journey document is the point of this repo. It is a warts-and-all record: every error message verbatim, every wrong turn, every claim retracted before delivery, and how each "it works" was actually checked.

Anyone can get an agent to generate a workflow. The interesting question is whether it can close the loop — build the thing, discover that it does not work, find out why, fix it, and produce evidence that the fixed version runs.

That loop is what this repo documents. Concretely, the agent:

1. Installed Activepieces in Docker and confirmed the API answered.
2. Read the flow schema out of the running container, because the operation it needed is not publicly documented.
3. Built a six-step flow as one JSON document and posted it to the API.
4. Ran it, and it failed. Six times, for six different reasons.
5. Diagnosed each failure from logs and source, fixed it, and re-ran.
6. Published the flow, forced a real run, and read back per-step statuses, HTTP codes and message counts.
7. Changed the requirement mid-flight (Inbox only, excluding Junk), then proved the change by querying two endpoints over the same window and comparing the counts.

Two of the four flow defects were the agent's own fault — a consequence of building through the API rather than the UI. The journey document says so plainly rather than hiding it.

This work started after watching 10 Open Source Repos BETTER Than Your Paid Subscription by Eric Michaud (2026-08-29), which features Activepieces. The first prompt of the session was simply to install it and explain what it does. The automation came second.

An hourly digest of new Inbox mail, sent to an address of your choice.

Design choices worth naming:

• A digest, not per-message alerts. Fifty messages at 09:00 should be one email, not fifty.
• Silence when there is nothing. The router stops the run at zero. Twenty-four "nothing happened" emails a day is worse than no automation at all.
• Microsoft Graph, not IMAP. Microsoft disabled basic authentication for personal Outlook.com accounts, so IMAP is a dead end for Hotmail.
• custom_api_call, not the findEmail action. findEmail has no date filter, so it would re-send the same messages every hour, forever.
• A Code step instead of the Date Helper piece. The Date Helper's output format is a fixed dropdown, and none of its fifteen options produce the ISO form with a trailing Z that Graph's $filter accepts. Three lines of JavaScript do.

Every claim was checked against the running instance. The full table is in section 7 of the journey.

One finding that only shows up when you actually run things: Activepieces' single-step test does not chain outputs from the preceding step. It uses stored sample data, which is empty on a fresh import. A variable renders blank and Graph returns Invalid filter clause. That looks exactly like a broken flow and is not. Only a published run proves the chain.

Counted node by node in section 4 of the journey.

The honest qualification, also in the journey: those 51 interactions are guided. The UI shows valid actions, validates as you type, and builds awkward structures for you. Two of the four defects exist only on the API path. On a first flow the trade is roughly even; on the fifth, or on a rebuild, it is not close.

git clone https://github.com/az9713/activepieces-flow-demo
cd activepieces-flow-demo
cp .env.example .env          # generate or paste AP_JWT_SECRET and AP_ENCRYPTION_KEY
docker compose up -d

Then open http://localhost:8080, create an account, and import hotmail-hourly-check.json. Before it runs you must set two things it cannot carry publicly:

1. A Microsoft Outlook connection, created in the browser. Only you can sign in to your own mailbox.
2. The placeholders YOUR_CONNECTION_EXTERNAL_ID and you@example.com. The connection is referenced by its external id, from GET /api/v1/app-connections — not by the name shown in the UI.

Two container flags are load-bearing, and the quickstart docker run omits both:

• AP_JWT_SECRET — docker-entrypoint.sh derives AP_WORKER_TOKEN from it. Without it the worker crash-loops with EnvVarError and no flow ever runs, while the web UI looks perfectly healthy.
• AP_INTERNAL_URL=http://127.0.0.1:80 — inside the container the API listens on port 80. Without it every run dies with ECONNREFUSED 127.0.0.1:8080.

Both are in docker-compose.yml. That is the whole reason the file exists.

• One flow, one session. This is a case study, not a benchmark.
• Two of the four flow defects were self-inflicted by taking the API path.
• The instance runs on a laptop. A missed hour is not retried — the next run asks only for its own 60 minutes.
• The agent could not complete the OAuth sign-in. A human must do that in a browser.
• Versions move. This was Activepieces 0.82.0, piece-microsoft-outlook 0.4.0, piece-schedule 0.1.22. The image tag latest resolved to 0.82.0 while the repo's main branch pinned 0.89.0.

MIT — see LICENSE. Activepieces itself is MIT licensed too.

• Activepieces — MIT licensed, self-hosted workflow automation.
• Eric Michaud — the video that prompted the session.
• Built with Claude Code.