Nothing to build. Nothing to pay.
You define the flows. Your customer turns one on when they need it, and Ngentix bills them directly. You see every customer connected and every flow running.
A flow is one source and everywhere it writes to. Sending the same order to three destinations is one flow, not three.
At scale, Ngentix runs in your own cloud.
Every other platform in this category bills you, and the bill grows with your customer count — typically a monthly platform fee plus a charge for each connected account. You pay nothing, at any number.
$15 is an introductory rate, and the console is free while we're building it out. Both may change as the catalog grows. Flows connected before they do stay where they started — you should never have to explain a price rise to a customer you already sold.
Start with the catalog. Point the engine at the rest.
The catalog is what we've already built. What differs across it is how much your customer has to do to connect — which is worth knowing before you promise them anything.
Click to connect
Your customer presses one button and approves it, on your page, under your name. Nothing for them to find, generate or paste. You register an app with each of these once — once per system, not per customer — and that registration is why they see you rather than us.
Customer supplies a credential
These systems have no consent screen. Your customer generates a key in their own account and pastes it in — or, for most ERPs, their administrator issues a token, which is several steps and usually a scheduled conversation. Nothing for you to set up; time for them.
Engine-built
Point the engine at an API, an EDI feed or a file drop and it builds you a connector. A documented, sensibly-named source gets you something close to a catalog connector. A badly documented one gets you fields the engine can't name, and someone on your side maps them. The builder is made for that work — but it is work, and we'd rather say so here than at first run.
Anything in the catalog can move data to anything else in it, in any combination — the engine maps between them directly rather than through a fixed schema, so you are not limited to the pairs somebody anticipated.
In the catalog, the mapping work is already done and you're confirming it. Outside it, budget time with someone who knows what the fields mean. Either way you aren't writing a connector. Which system is which.
So what do you actually have to do?
You don't write code. You make decisions about your data, and the engine does the rest.
Point the engine at each system.
For the systems that use OAuth, you register an app on their developer portal — once per system, not once per customer, and it's what makes your customer authorize your product rather than ours. For the ones that don't, there's nothing to set up on your side. And if a system isn't in the catalog at all, give the engine the endpoint and the auth and it builds the connector. Docs walk you through each one.
Confirm the few it isn't sure about.
The engine reads the source and maps what it's confident about, which is most of it. What's left comes to you as a question — where does this field go — with the engine's best guess already filled in. The confidence line that decides which is which is set to a sensible default; move it only if you want more questions or fewer.
Define the data points that move.
You decide which data points move, from one source to one or many destinations. One source and everywhere it writes to is a flow — that is our word for it, and it is the unit your customer pays for. Sending the same order to three places is one flow, not three. Your customer doesn't build anything; they turn on a flow you've defined.
Put it in your product.
A drop-in widget or the API — whichever fits how you ship. Some partners also run a connection page we host under their name; that one's arranged case by case rather than switched on, so ask if it's what you need.
Your customer clicks Connect. Data moves.
One button for most; a pasted key or an admin-issued token for the rest. They sign in to their own system, on your page, under your name. Records pass through Ngentix as your app's proxy and nothing is kept. The flow is on their bill from that moment.
You never own the maintenance.
Every integration your customer asks for is one someone has to keep working. Vendors change their APIs on their own schedule, and each change lands on whoever owns the connector. Here is one, start to finish, on an account nobody was watching.
- 00:00 The vendor ships a new version of their API No notice. Two fields renamed, one nested a level deeper.
- 00:04 The next sync fails and the engine catches it The connector it is watching is the connector it wrote.
- 00:31 It remaps what it is sure about cust_ref → customer_reference · billing.zip → billing.address.postal_code
- 00:58 The connector is rebuilt and re-tested against the live API
- 01:12 Flows resume. One field is below your confidence line It is held, not guessed at — the sync runs without it.
- Next login You answer one question about that field A sentence and a button, with the engine's best guess attached.
5 of 6 handled without you. The last one is a question, not a ticket.
The engine that built the connector is the one watching it. When the upstream API changes, it remaps what clears your confidence line and asks you about the rest — a sentence and a button, not a ticket. That is what needs you means on this screen, and it is the same line you set on day one.
FAQ
Who pays, and what does my customer see?
Ngentix bills your customer directly: $15 per flow, per month, only while data moves. You see every customer connected and every flow running in your console.
Your customer connects on your page, under your name, and authorizes your product — because the developer app is yours. Ngentix is the plumbing behind it.
What if you don't have the connector my customer needs?
Give the engine the endpoint and the auth and it builds the connector: reads the API, maps what it’s confident about, asks you about the rest. How good the result is depends on the source — a documented, sensibly-named API gets you close to a catalog connector, and a badly documented one gets you fields the engine can’t name, which someone on your side maps. The catalog is what’s already built, not the limit.
What exactly is a flow?
A flow is one source and everywhere it writes to. Shopify orders going to HubSpot, Slack and Airtable is one flow, not three — you are billed for what you set up, not for every system it touches.
You define the flows; your customer turns on the ones they want. $15 per flow per month, billed from the moment they turn one on.
What happens when their API changes?
The flow repairs itself and you see a count. Changes that need a human decision — a new field, a scope change — reach you as a sentence and a button. Not a ticket, not a sprint.
What do I actually have to build?
You don’t write a connector. You point the engine at each system, confirm the mappings it wasn’t sure about, and define the flows — which data moves, and where. That work needs someone who knows what the fields mean, not someone who writes integration code. Then a widget or the API puts it in your product, and your customer turns on the flows you defined.
What if the engine maps something wrong?
Set the line higher and more comes to you as a question; set it lower and more goes through on its own. Every mapping is visible and every one can be overridden. The engine shows its best guess with the question, so most answers are a yes.
Where does the data live?
It doesn’t, with us. Records pass through Ngentix as your app’s proxy, from your customer’s system to the destination, and nothing is retained. Flows run in Ngentix’s cloud; at scale, they can run in yours.
What if I want to leave, or run it myself?
Your developer apps are yours; they don’t depend on us. At volume, Ngentix runs in your own cloud on an enterprise license.
Ship the integration they asked for.
Two fields, and a person replies — usually the same day. Your customer pays per flow; you pay nothing.