It can also make API calls itself as part of the workflow if you want it to send data or retrieve data from other sources.
Think of it less like something like Zapier which is designed for piping data from A to B, and more like user-friendly wrapper for something like Express.js to make it more consumable to people who: A) Can't code, or B) Don't want to have to spend 30 mins spinning up a serverless instance to hook some webhooks and API's together.
That last point is particularly important when combined with the fact that Workflows can be imported into each other effectively like "Functions" so you can reuse blocks of logic.
The fundamental "atomic use-case" is Product A which has Webhooks, and Product B that has an API. You want to get the data from Product A's webhook, mutate it, update it, maybe cross-reference it with Product C, and then push it into Product B. This kind of logic is prohibitively complex with tools like Zapier (and also quite expensive for an individual), and often legacy tools don't enjoy any of the benefits of tools like Zapier anyway because they don't have native connectors for them.
Appreciate the feedback re: the messaging - I agree that the distinction between this and something like IFTTT/Zapier is important to communicate.