Workflows.
A tool answers one question. A workflow answers a job: take this value, check it, reshape the result, hand it back. Up to 12 steps in a fixed order, where every step can use what an earlier one produced.
Why you would want one
Because the work you actually have is rarely a single tool.
Doing a job by hand means opening one tool, copying the answer, opening the next tool, pasting it in, and repeating that every time the job comes round. A workflow is that sequence, saved once. You give it the value it needs, it runs the steps in order, and it hands you the end result. The same saved workflow can then be run from your own code, so the thing you worked out by clicking becomes something a script can do at three in the morning.
How many you can have, and where each one is kept
The two questions have different answers, and the second is the one people are surprised by.
| How many | Where it lives | |
|---|---|---|
| Signed out | 1 | In this browser. This is saved by your browser on this device. It is not sent to ToolForte, so it is not on your other devices and we cannot recover it for you. Clearing your browser data removes it, and so does the delete button here. |
| Free account | 2 | On our servers. This is stored on ToolForte servers, tied to your account, so you can reach it from any device you sign in on. |
| ToolForte Pro | No limit | On our servers, the same as a free account. |
You do not need an account to build one. The builder works signed out, and the workflow you make there is a real workflow: it saves, it reloads, and it runs. What it does not get is a server, so clearing your browser data loses it and a second device never sees it. Signing up moves that story rather than changing what a workflow is.
If a subscription ends
Nothing is deleted. That is the whole promise, and it is worth stating before the detail.
An account that built more workflows while paying than a free account may keep does not lose any of them. It keeps every one. What changes is how many it can run: the oldest 2 stay runnable, which is exactly what a free account gets, and the rest are locked. Resubscribe and all of them work again immediately, with nothing to restore, because nothing was taken away.
Oldest rather than newest is deliberate. Under a newest rule the two that worked yesterday might not be the two that work today, because editing one would reshuffle the set. The oldest 2 are the same 2 forever, which is a promise that can be printed.
Folders, order and names
Housekeeping, once you have more than a handful.
| Folders | One level. A folder cannot go inside a folder, which is a property of how they are stored rather than a rule that could be relaxed by accident. |
| Deleting a folder | Never deletes the workflows in it. They come back out into the loose list at the top. The folder was a label you chose, and losing a label is not a reason to lose the work. |
| Order | Drag to reorder, within a folder or between folders. The order is stored on our servers, not in your browser, so it is the same after you sign out and sign in on another machine. One drag is written in one go, so a move cannot half happen. |
| Renaming | Name and description can be changed in place at any time, and neither affects the id, so anything already calling that workflow from a script keeps working. |
Starting from a template
12 ready-made workflows, each built for one real job rather than to demonstrate a feature.
Adopting one copies its definition into your own list. From that moment the two have nothing to do with each other: editing your copy does not change the template, deleting your copy does not remove the template, and if we change a template here it does not reach back into a copy anybody already made. The copy remembers which template it came from, and that is all that connection is.
Check a new client's bank account number, VAT number and billing email before you invoice them, and work out what the invoice comes to with VAT added.
A freelancer or bookkeeper in the Netherlands who has just taken on a client and does not want to find out three weeks later that the payment details were wrong.
Make a matching batch of fake but structurally correct Dutch identities in one go: a record id, a bank account number and a citizen service number for each test person. None of them belong to a real person or a real account.
A test engineer at a Dutch insurer, pension administrator or government supplier who needs a fresh set of identities every sprint and is not allowed to copy production data.
Take a title and a draft written in Markdown and get back everything the website needs: the word count and reading time, the web address for the page, and the finished HTML ready to paste in.
Someone who writes for a company blog or a help centre, drafts in Markdown, and has to hand three separate things to whoever runs the site.
Paste in a scrambled Base64 blob from a log line, a queue message or a webhook, and read it back as tidy, indented JSON.
A developer looking at a failed message and needing to see what was actually in it, without pasting customer data into whatever decoder comes up first in a search.
Work out the gross and net vakantiegeld for a monthly salary, and how much of the gross actually reaches your account after the special tax rate.
Anyone employed in the Netherlands who wants to know what lands in May before it lands.
Find the state pension date for a birth date, then count the days, weeks and months between today and that date.
Anyone in the Netherlands born after 1956 who has heard the AOW age keeps moving and wants their own date.
Monthly payment, total paid and total interest for an annuity loan, plus the interest as a percentage of what you borrowed.
Anyone comparing two loan offers, or wondering what an extra half percent does over thirty years.
Take a percentage off a price, add VAT, and divide what is left between the people paying.
Anyone who has stood at a till or a restaurant table working this out on a phone calculator.
Reading time, the words you lean on most, and a URL slug from the title, so a piece is ready to publish without three separate tools.
Anyone who writes for a site or a newsletter and wants the numbers editors ask for.
Paste CSV from a spreadsheet, get a Markdown table and the same table as HTML you can drop into a page or an email.
Anyone who keeps a list in a spreadsheet and needs it on a web page or in a document without retyping it.
Parse a YAML file, get it back as JSON, and derive TypeScript interfaces from the result.
A developer with a config file and a strongly typed codebase that has to read it.
Count the days, working days and weeks between two dates, and find the ISO week number of the deadline.
Anyone planning towards a date: a delivery, a move, an exam, a launch.
A worked example
Say you get bank details from customers and you want two things at once: is this IBAN real, and what is a clean, URL-safe name for the country it belongs to. That is two capabilities, and the second one needs what the first one found.
What it looks like
| The workflow | |
|---|---|
| Workflow input | One field, iban, which you type when you run it. For example NL91 ABNA 0417 1643 00. |
| Step 1 (1) | IBAN Validator. Check whether an IBAN is well formed: the mod-97 checksum, the country's own length, and the character layout each position must have. Splits the number into its parts, verifies the national check digit for twelve countries, and names the bank for Dutch IBANs. A format check, not a bank check. Its iban field is wired to the workflow input. |
| Step 2 (1) | Slug Generator. Turn any text into a URL-safe slug, folding diacritics and stripping punctuation. Its text field is wired to step 1, at the path countryName. |
What comes back
Step 1 returns an object. Step 2 reads one field out of it and turns that into a slug, which is the result of the run.
{
"valid": true,
"iban": "NL91ABNA0417164300",
"country": "NL",
"countryName": "Netherlands",
"checkDigits": "91",
"bankCode": "ABNA",
"accountNumber": "0417164300",
"institution": {
"name": "ABN AMRO",
"kind": "bank"
}
}Step 2 takes the value at countryName and returns an object of its own, with "slug", "originalLength", "slugLength" in it. The last step's output is the result of the run, and the run panel shows you every step's output in full rather than only the last one.
That run costs 2 credits: 1 for the first step and 1 for the second.
The three pieces
Everything in the builder is one of these.
One capability call each, in the order you put them. You can give a step your own label, so the builder and the run panel read like your job rather than like our catalogue.
The values you supply when you run it. Each one has a name, a label, a type, and whether it is required. Give it an example value and the builder prefills it, so the workflow can be tried without thinking.
For every field a step needs, you choose where the value comes from. There are exactly three choices, below.
Where a step gets its values
Each field of each step is wired to one of three sources. This is the whole wiring model; there is nothing else to learn.
| Source | When to use it |
|---|---|
| A fixed value | You type it in the builder and it is the same on every run. Good for settings: the separator for a slug, a VAT rate, a date format. |
| A workflow input | The value is supplied at run time. Good for the thing that changes: the IBAN in the example above, the text to check, the amount to convert. |
| An earlier step | The value is read out of an earlier step's output. You pick the step and give a path into its result, so step 2 can work on what step 1 found. |
Paths, in one minute
A step output is usually an object, and a path names the piece you want. Dots go one level deeper and numbers pick an item out of a list. In the example, step 1 returns an object with valid, iban, country and countryName, so the path countryName gives you "Netherlands". A path like results.0.value would take the first item of a list and read one field out of it. Leave the path empty and the next step gets the whole output.
A path that leads nowhere is treated as a mistake, not as an empty value. The run stops and tells you what that step actually returned, because passing nothing along quietly would turn one wiring error into a confusing failure two steps later.
Test it before you save it
The builder has a test run. Fill in the inputs, press it, and you see every step, its output, and how long it took, before the workflow exists anywhere.
The difference is what the steps need. A workflow whose every step is pure computation can run on your own machine, so nothing reaches our servers and nothing is charged. Add one step that needs our servers and the whole run goes back to being metered as usual, at one credit per step. Running the same saved workflow over the REST API or from an AI assistant is always charged, because there the work really does run on our hardware.
You are shown the real output of every step, not a prediction of it. When a step could not run, the panel names that step and says what went wrong in words you can act on. And when a tool ran with something other than the value your step handed it, the run says so against that step: a "Heads up" line naming the field, what was supplied, and what was used instead. That line is worth reading even on a run that succeeded, because the output below it is correct for what the tool actually used.
Fix what the run tells you, run it again, and save it when it does what you meant.
Steps run in order, and nothing branches
This is the one thing worth reading twice, because it is where expectations usually break.
A workflow is a straight line. There is no "if this, then that", no loop, and no step that runs only sometimes. Every step runs, in the order you put them, and each one may read the steps before it.
The verdict is in the output of the step that made it, under valid, and the run panel shows you that output in full. Nothing hides it. But nothing acts on it either, so put the check where its answer reaches you: make the validation the last step, so the result of the run is the verdict itself, or keep the later steps and read valid yourself before you act on the rest.
What does stop a run
A run stops at the first step that genuinely fails: a capability that refuses the value it was handed, a path that points at nothing, a missing required workflow input, an empty credit balance, or the whole run passing its 25 second budget. You are charged for the steps that ran, not for the ones that never started, and the result names the step that stopped it.
What a run costs
When the work happens on our servers: the sum of its steps, and nothing on top.
Each step is paid for immediately before it runs, so a run that stops halfway charges for the half that happened. Most capabilities cost 1 credit, so a short workflow of ordinary checks and conversions costs a handful of credits; a step that renders a PDF or asks a language model costs more, and the builder shows the price of each step as you add it. Credits and plans has the full price list.
Where your runs are recorded
Open a workflow and its history is on that page.
Your workflows lists everything you have saved, with how often each one has run and when it last did. Open one and you get its editor plus its recent runs. The history is one row per run: when it happened, where it was run from, whether it succeeded, which step stopped it if it did not, how long it took and how many credits it cost.
The history is what a server run buys, so it only holds server runs. A browser run puts no row here and does not move the run count. That is the same fact as it being free, seen from the other side, rather than a second rule to remember.
One exception, because "leaves nothing behind" would be the easy sentence and it is not quite true. When a browser run finishes we record that it happened, which ready-made workflow it came from if it came from one, how many steps it had, whether it finished or stopped at a failing step, and how long it took. Never what you put in, never what came back, and never anything written into the steps themselves, nor the workflow's name or id. It is how we can tell which tools and templates are worth keeping. The same sentence is on the page next to the run button, so you do not have to come here to find it.
The step-by-step detail - each output, and any "Heads up" about a value that was substituted - is shown by the run panel at the moment you run it, so it is worth reading then rather than looking for it in the list afterwards. A very large output is stored shortened, and where it is shown it says so rather than pretending to be the whole value.
For the money side of the same picture, your usage page shows what has been spent across everything, as far back as your plan keeps history.
The limits
A workflow is a convenience, not a compute platform. Every limit exists so that a mistake in a definition cannot become a surprise bill or a stuck run.
| Steps | Up to 12 per workflow |
| Workflow inputs | Up to 10 |
| Time for a whole run | 25 seconds, after which it is stopped and recorded as a timeout |
| Name and description | 80 and 400 characters |
| Output kept per step | 20,000 bytes in history, shortened above that |
Running a workflow somewhere other than this site
A saved workflow is not only a page here. It has an id, and that id is callable.
With an API key you can run it over the REST API and get the same result back as JSON, which is how a workflow you built by clicking ends up inside a nightly job or a form on your own site. The id in the URL is the one in the address bar when the workflow is open.
curl -X POST https://toolforte.com/api/v1/workflows/YOUR_WORKFLOW_ID/run \
-H "Content-Type: application/json" \
-H "X-API-Key: your_api_key_here" \
-d '{"inputs": {"iban": "NL91 ABNA 0417 1643 00"}}'Your AI assistant can run it too. Connect Claude, Cursor or another MCP client to ToolForte with an API key and it gets two tools: workflow_list, which returns your saved workflows with their ids, the inputs each expects and what a run costs, and workflow_run, which runs one by id. The assistant calls the first to find out what exists, then the second. It is the same engine and the same price as running it here.
If any of your workflows are locked because a subscription ended, the list marks them and says why, so your assistant can pick a runnable one instead of finding out by being refused. Locked ones are still listed and still counted, because one quietly vanishing from the list would look like it had been deleted, and nothing is ever deleted.
How it knows the workflows are yours
Both surfaces authenticate with the same API key you create on your account page, sent as an X-API-Key header over REST and as an Authorization: Bearer header to the MCP server. A workflow belongs to an account, never to a key and never to a session, so every call resolves whose account the key belongs to first and then looks for the workflow inside that account only.
There is no way to reach a workflow from the outside. Asking for one that belongs to somebody else returns exactly what asking for an id that does not exist returns, because a distinct "forbidden" would confirm the id is real. A key that was never linked to an account has no workflows at all, rather than having access to some default set. API and MCP covers keys in full.