Built for connections that move under you.

What it builds, and where it stops.

The engine reads an API and writes the connector: discovers the surface, infers the mapping, tests it, and repairs it when the far side changes. 107 systems are in the catalog today. The catalog is what's already built, not the limit.

Every mapping is scored — how confident the engine is that a field on their side means what it appears to mean. Above the line it maps on its own; below it, a named person answers a question with the engine's best guess attached. The same line governs what gets repaired later without asking. It ships at a sensible default per connector, and it is yours to move when a source deserves more scrutiny or less.

Two ways to run the same engine.

The question is never where the software sits. It's who keeps it healthy, and whether the data leaves your environment at all.

In both cases Ngentix is a proxy for apps you register yourself: your administrator authorizes access to each vendor under your name, records pass through, and nothing is retained. What differs is whose account they pass through, and who operates the engine that moves them.

What your security and legal teams will ask for.

The detail behind each of these — what crosses which boundary, what is persisted, and where flows run — is in Architecture and data handling.

You run it. We keep it working.

A license, not a managed service. The stack deploys in your cloud or your datacenter, for as many users and as many flows as you like, and you use it as you see fit.

The clause that matters most is the last one. Every defect we fix is published to every deployment, so a breakage another licensee hits is fixed before you hit it — and you choose when it goes in, inside your own change window. That is the thing self-hosting normally costs you — you take the perimeter and give up the fleet's learning. Here you keep both.

Named actors, rules, approvals, and a record.

Every action on the map has a name against it — a person or an agent — the rule that allowed it, who approved it if approval was needed, and a record that outlives the conversation.

Ngentix · control plane

The audit question stops being a project. When someone asks who changed a field, or why a record moved, the answer is a query rather than a reconstruction — and it is the same answer six months later, when the people involved have moved on.

Thirty, sixty, ninety.

What the first quarter looks like when it goes well. One connector, your own systems, your own data.

Where support starts and stops.

Worth being exact, because a vague boundary here becomes an argument later.

You don't have to believe we'll be here in three years.

Every vendor gets asked what happens if they're acquired, or if they fail. Most answer with a promise.

Ours is structural. The developer apps are registered to you, not to us — the authorizations your administrators granted survive us. You operate the engine in your own account, which means the thing you depend on is already inside your perimeter, on infrastructure you control, running whether or not we answer the phone. A buyer who could operate it themselves doesn't need a promise about our future.

Buyers usually have to negotiate data-portability and exit terms into a contract. We'd rather offer them: mappings and flow definitions export in a documented format, and the apps stay registered to you.

The smallest version of yes.

Nobody should stand up a deployment to find out whether an engine works. So don't. Run it on our hosted infrastructure first, against one real system, and move it in-house once you know.

Questions a committee asks.