WordPress · automation

Automation that lives in your site, not someone else’s cloud.

When something happens on your site, Flow Forge does the next thing — and the one after that. You build it in a form, not a JSON box; you start from one of twenty ready-made recipes; and with Pro a flow stops and waits when the next step needs a yes from a person. The runs happen in your own WordPress, so nobody meters them by the task.

See what it does See pricing

being forged — launching with the Avakode suite

flow order paid run #1

Order paid


        order.total 320 · USD · DE

Post to Slack #orders
Hand off to Lang Forge no credentials needed
Call a webhook your CRM
Note on the order what ran, and when

34 triggers · 34 actions · no task meter

No JSONevery trigger and every step draws its own form — the textareas are the fallback, not the interface

20ready-made recipes, every id in them real — and one this site cannot run names the plugin it needs

No evalconditions are compared, never executed; an expression is just a string

The chain

One event in. A chain of work out.

34 triggers and 34 actions, wired in a builder and executed inside your own WordPress — no task quota, no third party holding the payload. Conditions are compared, not evaluated: the 2 rules below that try to smuggle in an expression are simply refused.

the event, as it arrived

order.total 320  ·  order.currency USD  ·  order.status processing  ·  order.email [email protected]  ·  customer.country DE  ·  customer.orders_count 4

condition expression verdict

Order over 200 order.total greater_than 200 matched

Paid in USD order.currency equals USD matched

Repeat customer customer.orders_count greater_than 1 matched

Shipping outside Germany customer.country not_equals DE no match

Work e-mail order.email contains @example.com matched

Smuggled PHP expression order.total equals phpinfo() refused

Unknown operator order.total eval 1 refused

4 conditions matched — the steps run

34 triggers · 34 actions · 3 retries then the dead-letter queue

An unknown operator never matches, and a value that looks like an expression is treated as a string. That is not a setting — there is no code path that would run it.

Recipes · forms · approvals

The flow you meant, without a line of JSON.

A form for every step, twenty recipes to start from, a human in the middle when the next step needs a yes, and one button back from a run that failed.

A builder, not a JSON box

Every trigger and every step draws its form from the schema it already declares. Conditions are rows — field, operator, value — and next to each text field a menu drops in a value from the event with a real example beside it.

Twenty recipes to start from

A form submission into Slack and your CRM, an order into a webhook, a locked-out IP to your team. Import lands a draft, never a live automation, and a recipe this site cannot run says which plugin is missing instead of greying out a button.

A person in the middle (Pro)

The run pauses and one approver gets an e-mail with two links. Whichever they click is recorded, the flow carries on from exactly where it stopped, and every later step can read who decided and what they decided.

One button back from a failure

A run that gave up shows the step, the error and a preview of what it was carrying, with anything token-shaped blanked out. Retry starts a new run at that step with the original payload — the steps that already succeeded do not run twice.

A flow can react to a flow

When a run exhausts its retries it fires a trigger of its own, so another flow can page someone or open a ticket. Once per failed run, and a flow can never be started by its own failure.

Conditions without code

Field comparisons grouped with AND/OR. Nothing is evaluated as an expression, so an automation cannot become a way to run PHP on your site.

The catalogue

34 things that happen. 34 things to do about them.

Not thousands of apps — the ones your site actually has. Posts, users and roles; orders, refunds and stock; and the other Forge plugins, which need no credentials at all because they are already here.

when this happens 34

Post published User registered Comment approved Role changed Order created Payment complete Refund issued Low stock Guard Forge · IP locked out Lang Forge · translation done Rank Forge · audit finished Form Forge · submission +22 more

then do this 34

Send an e-mail Create or update a post Add a user to a role Post to Slack Post to Telegram Call a webhook Note on an order Hand off to another Forge plugin +26 more

Values from the event drop into any field of any step — {{event.order.email}} is a field, not a formula. The builder is plain JavaScript, so the canvas loads without a framework behind it.

Building one

Import a recipe, fill in the form, read the runs.

Start from a recipe

Twenty ready-made flows, grouped by the plugin they lean on. Import one and it lands as a draft with its steps already in order.

Fill in the form

Every parameter is a labelled field, and the picker drops values from the event into any of them. The JSON is still underneath, if you ever want it.

Read the runs

What fired, what failed, what it was carrying. A run that gave up names the step it stopped on and offers the button that starts it again from there.

Three in the morning

Break the step. See what it does when nobody is awake.

Any of the 34 actions can fail — a token expires, a CRM is down. Three attempts with backoff, then the run parks where you can see it. And when the sender retries the same delivery, the flow refuses to run twice.

run Order paid → notify and sync 03:00

Post to Slack delivered
Note on the order written
Call the CRM webhook parked in the dead-letter queue

03:00:01 step 1 · slack.post · 200 OK
03:00:01 step 2 · order.note · written
03:00:02 step 3 · webhook.call · attempt 1 · connection refused
03:00:04 step 3 · backing off
03:00:06 step 3 · attempt 2 · connection refused
03:00:11 step 3 · backing off, longer
03:00:19 step 3 · attempt 3 · connection refused
03:00:19 run parked · payload and error kept · replayable

not run twice The sender delivered the same event again. It is HMAC-verified, matched against the event hash already recorded, and refused — a retrying webhook cannot double-charge anyone.

Three attempts, then parked with its payload — and the duplicate delivery refused.

Already on the site

Wires up to

WooCommerce

Slack

Webhooks

Guard Forge

Rank Forge

Lang Forge

Form Forge

Comparison

Flow Forge vs a hosted automation service

What you are comparing	Flow Forge	a hosted service
Where the work runs	Inside your WordPress	On their servers, holding the payload in transit and at rest
What another thousand runs cost	Nothing — there is no task meter	Metered, per task or per operation
Reaching your site’s own data	Directly: posts, users, orders, meta	Through the REST API, with credentials to store somewhere
Talking to the rest of the suite	No credentials at all — the other Forge plugins are already here	An API key and a connection per app
A step that waits for a person	With Pro: the run pauses on an e-mailed yes or no and continues from where it stopped	Another step in the chain, metered like the rest
Breadth of the catalogue	Shaped like WordPress: posts, orders, users, and the Forge plugins next door	Thousands of apps, most of them nothing to do with your site their win
Scheduled work	Leans on wp-cron, which needs traffic to fire on time	Runs on their clock whether anyone visits or not their win

If most of what you automate never touches your site, a hosted service is the better buy — that is the job it was built for.

Pricing

One licence, no task meter — credits only when the AI drafts.

No upsells, no surprises.

Personal

$49 /year

1 site

Get it on avakode.com

What runs where in Flow Forge

Which work happens inside your own install, what leaves it, what needs a paid plan, and what a lapsed licence leaves behind.

What the free tier does inside your own install

Twenty ready-made recipes, and no JSON to write
Retry a failed run from the step it failed on
Visual flow builder (form editor and drag-and-drop canvas), unlimited active flows

What leaves your site when a feature is on, and where it goes

Usage telemetry is off until you switch it on: every send reads the site option `forge_telemetry_consent` first, and stops when it is not "1".
With telemetry on, batches of events POST to https://api.avakode.com/telemetry/batch.
The in-admin feedback form POSTs your rating and comment to https://api.avakode.com/feedback when you press Send.
The Forge Suite dashboard health card GETs https://api.avakode.com/health.

What needs Pro, credits or an outside service

Pro is a separate plugin. With no Pro add-on loaded the plan is free, whatever is stored in the database.
Licence activation and every AI request go to https://api.avakode.com.
AI actions spend credits from your Avakode balance; the price per action is decided on the server (1 credit for a translation, 3 for a whole post).
A request over 10,000 tokens costs a multiple of the base action price.

What happens when the licence lapses

Free features keep working. The wp.org base ships no licensing SDK: without the Pro add-on answering "pro" through the `forge_pro_plan` filter the plan reads free.
When the paid ladder answers "free" in so many words, the stored grace marker `forge_license_last_pro_at` is cleared and Pro gates close on the next admin request.
Pro keeps working for 6 hours of silence from the licence server — that window covers an outage, not a revoked licence.
A lapse removes no data. Tables and options go away only when you uninstall the plugin.

How long data is kept, and how you take it out

Run history is kept 30 days by default; the setting accepts 1–365.
A scheduled collector deletes runs past the retention setting.
Pro downloads recipe packs as files.
There is no export of run history itself; the only CSV export in the codebase is the suite's shared cross-product results summary, unrelated to individual flow runs.

The same five questions for every tool →

Switching

Nothing to migrate, and nothing holding you.

Nothing to migrate

Flow Forge imports nobody else’s flows. Start from one of the twenty recipes, build the two or three that actually run every day, and leave the rest where they are.

It runs alongside what you have

Nothing conflicts: keep the hosted service for the cross-app work and let the site-shaped work happen on the site.

Leaving costs you nothing

Deactivate and the flows stop. The runs and their history stay in your database until you delete the plugin — and even then the tables are kept unless you tick the box that says otherwise.

FAQ

The questions people bring from Zapier

Why not just use Zapier?

Because the work happens here. There is no per-task price, your payloads do not leave the server, and anything involving another Forge plugin needs no credentials at all. The honest tradeoff: scheduled work depends on wp-cron, which needs traffic.

Do I have to write JSON?

No. Every trigger and every step draws its form from the schema it declares, and conditions are rows of field, operator and value. The JSON textareas survive under an “Advanced” toggle, and anything the form cannot draw honestly — a nested condition group, a key no schema knows — opens as JSON with an explanation rather than being quietly rewritten.

What happens when a run fails at three in the morning?

It is kept, not dropped. The Failed view names the step it stopped on, the error, and a preview of the payload with anything that looks like a token blanked out. One button starts a new run at that step with the original payload — and it is refused outright if you have edited the flow since, because that step is no longer that step.

Can a flow wait for a person?

With Pro. The run pauses, one approver gets two links, and the decision comes back into the flow — who decided, what they decided, when. Only a hash of the link’s token is stored, a second click cannot change the answer, and you choose in advance what silence means when nobody replies: rejection, which is the default, approval, or stop.

Can a flow break my site?

Conditions are data — the evaluator runs no arbitrary code, and an unknown operator simply never matches. Steps retry and then park where you can see them, and the trigger that fires on a failed run refuses to start the flow that failed, so an alarm cannot become a loop.

What happens if a webhook is delivered twice?

It runs once. Deliveries are verified with HMAC and de-duplicated on a unique event hash, which is exactly the case most automation tools get wrong.

Wire it up