Integration Pipes

The problem with renting your integrations

Most integration platforms are a subscription to somebody else’s cloud. Pricing is per task, per run or per step — so the better your automation works, the more it costs, and teams start avoiding automation to control the bill. Meanwhile every invoice, payroll file and customer record passes through infrastructure you don’t own, reachable only through an agent or a firewall change, backed up under someone else’s policy, on someone else’s maintenance schedule.

Integration Pipes is built on the opposite premise: the platform comes to your infrastructure, not the other way around. Nowhere your data goes is outside your network. Nothing about your cost depends on how well the automation works. And if the terms of another vendor’s product ever change, nothing about yours does either — it’s already inside your walls.

How it deploys

• As a Windows service — installed on your servers, started with the machine, managed like anything else on your estate. Upgrades are a matter of replacing and restarting the service.
• As Docker containers — two images onto your existing container orchestration, managed with the tooling you already use. Upgrades are a matter of rolling a new image.

Both share a single SQL Server database — the same one your DBAs already back up, and the same place encryption keys for stored credentials live, so nothing has to be copied between machines when you add a server. It’s built on .NET 10 and runs on Windows directly, or on any host that runs Linux containers. Desktops need nothing installed at all — just a browser. Configuration is standard config files, overridable by environment variables, so the same image promotes cleanly from test to production.

The choice doesn’t change what the product does or what it costs. It is the same platform either way.

Two moving parts, both yours

The Console is the browser-based interface where people design workflows on a drag-and-drop canvas, manage who can see what, review everything that ran, and administer connections to outside systems. Nothing to install on a desktop.

The Engine is the background service that does the actual work. It runs whether or not anyone has a browser open, watches folders and mailboxes, answers incoming web requests, and keeps to the schedule. Because it sits inside your network, it reaches your database, file shares and internal APIs without any of them being exposed to the internet — no inbound firewall changes, no gateway agent to license and babysit.

Need more throughput? Run the Engine on several machines at once, sharing the queue, at no additional licence cost — because the hardware is already yours.

A palette that covers the real work

79 built-in components across 14 categories and 13 connection providers, all included, none gated by tier:

• Logic & flow control — branch on a condition, switch between named routes, park a run for human approval, or aggregate parallel branches back into one
• Files, FTP/FTPS, SFTP and Box — read, write, transfer, zip, checksum and AES-256-GCM encrypt, against local disk or any of the three
• Bulk readers — CSV, Excel, MSSQL, folder listings and OData, each able to fan out one parallel branch per row, file or record with a concurrency limit you set
• Cloud storage & databases — SharePoint, OneDrive, Google Drive and AWS S3 copies; run statements, upsert or copy tables in SQL Server
• Email, Microsoft Teams, web services and authentication — send and file mail, post to a Teams channel, call any API, mint and refresh OpenID Connect tokens

Plug-ins add whole systems, not just steps

A plug-in is a single file dropped into the platform and enabled from the admin screen. It can add components and its own connection type, and the Engine picks it up without a full redeploy. Three ship with the product today: Telegram and WhatsApp messaging, and a step for putting a language model into a workflow — reading a supplier invoice, classifying an inbound email — with token usage returned on the payload so it can be logged or capped.

Most systems, though, expose a web API, a database or a file drop — all of which the built-in components already cover. Where a system is genuinely unusual, or you need a connector nothing on the palette handles, our engineers can build it as a new component or connection and get it added to your deployment, rather than you waiting on the general product roadmap.

Workflows that handle the real world

Every component declares a shape, and the shape determines how it can be wired — the difference between this and a list of scheduled scripts:

• Routing — a condition sends a run down True or False; a switch picks between named cases; an approval step emails or messages a person and resumes down the branch matching their answer, even if that takes days
• Fan-out and aggregation — read ten thousand rows and process them in parallel, with a concurrency limit so the downstream system is never swamped, then collect the results back into one summary
• Error and empty ports — a bad record diverts down its own branch for review instead of ending the run, and “nothing found” is treated as a real answer rather than mistaken for success
• Retry — each step carries its own attempt count and delay, because most failures are temporary and resolve on the second try

A single workflow can put all four to work at once: a schedule fires at 23:00, reads the day’s completed orders from SQL, and fans that query out into one branch per order. Each branch builds a summary, files it in the right client folder in SharePoint, and emails the account manager. Three orders with a malformed address divert down the error port into a review list instead of failing the run; the other few thousand complete normally, and one exception email is waiting in the morning.

Built to survive an audit

• Workspaces divide work by department, client, environment or project — Finance cannot see HR’s workflows
• Four access levels — Viewer, Member, Contributor and Admin — granted per workspace, so some people design and others only run or watch
• Single sign-on through Microsoft, Google or any OpenID Connect provider, with local sign-in always available so a misconfigured provider can’t lock anyone out
• Complete run history, down to a single step’s payload, with values marked secure automatically stripped before anything is written to a log
• Credentials held centrally — a connection is defined once and referenced by name, so revoking access is one action, not a hunt through dozens of workflows

From nothing to running, typically inside a week

1. Installation — we deploy the Console and Engine into your environment, as Windows services or containers, and connect them to your database. Usually done in a day.
2. Foundations — workspaces, roles, sign-on, and the connections to the systems you want to reach, using whichever credential method your security team prefers.
3. First workflows — we build your first automations alongside your team, so knowledge transfers as we go rather than afterwards.
4. Handover — your people build the rest. That’s the point: the person who understands the process can automate it without waiting on a developer. We stay available for support, upgrades, and the occasional complicated one — or the occasional missing component.

Typical use cases

• Moving data between systems that were never designed to talk to each other
• Scheduled imports and exports that currently run as fragile scripts on someone’s machine
• File-drop and email-triggered processing that today depends on a person remembering
• Partner-facing web requests, each caller given their own login rather than a shared key
• A finance or operations spreadsheet dropped into a watched folder, landing in the target system seconds later with a confirmation email back to whoever dropped it
• Internal automations that a metered platform would make too expensive to justify

Common questions

• Do we need developers to use it? No. Workflows are built visually by the people who understand the process. A scripting step exists for genuinely unusual requirements, but most workflows never touch it.
• What happens if something fails at 3am? It records exactly which step, which record, and what error — and can email whoever needs to know. Expected problems can be routed down a path you design, so they’re handled rather than merely reported.
• Is there a limit on users, workflows or connections? No. There’s no usage metering in the product to enforce one.
• What if we want to stop using it? Your data was never anywhere else. It’s in your database and your file systems, in standard formats, on hardware you own.
• Can it connect to something not on the list? Most systems expose a web API, a database or a file drop, all of which are already covered. Where something is genuinely unusual, we can build a plug-in for it and drop it in.

What it stores

Workflows, run history and configuration live in your own SQL Server database, administered through a browser. Nothing about how it runs depends on an outbound connection to us — export a workflow to a file and import it into test or production, and it arrives switched off with credentials deliberately blank, so nothing runs against the wrong system by accident.