A Custom Connector in a Week, Without Forking the Product

Every company has one. A legacy ERP with a SOAP interface from 2009. An internal service that speaks a bespoke JSON. A supplier portal that only exports CSV over SFTP at 3 a.m. with a different column order each quarter. It is never in anyone's connector catalog, and it holds data the business cannot do without.

This post explains what we do with that system: how a custom connector is built, what it costs, why it is never a fork, and how we decide when it stops being custom.

The two ways this usually goes wrong

The vendor says no. The hosted ELT service does not support the system and will not. The customer writes a script around the edge of the platform, which is now the one pipeline that fails differently from all the others.

The vendor says yes, and forks. A consultant modifies the product's core to handle the system. It works until the next upgrade, which the customer can no longer take. Two years later they are on a version nobody else runs.

Neither is acceptable. The first leaves the problem with the customer; the second leaves the customer with the vendor's problem.

How it is built

Revoluzen Flow has an extension layer for exactly this. A custom connector is written against published interfaces, packaged as a versioned extension, and installed beside the catalog connectors. The core is untouched.

The package, at a fixed price, covers:

1. Authentication, whatever the system needs: basic, token, OAuth, certificate, or the thing it invented itself.
2. Pagination and incremental reads, so the connector reads what changed rather than everything, with a reliable cursor.
3. Schema mapping, from the system's types and names to consistent, typed columns, with a documented mapping.
4. Error handling, including the system's own habits: rate limits, partial responses, the export that is sometimes empty.
5. Test coverage against recorded responses, so the connector can be re-verified without the live system.
6. Packaging and a compatibility check against the current release, so the next Flow upgrade checks the connector along with everything else.

A bounded REST, SQL or file interface is the standard package. Change data capture, non-standard request signing or a multi-system workflow are quoted from a higher base, because they are more work and we say so up front. See the services price book.

A worked example

A distributor's pricing engine is an internal service with a JSON API that returns nested price lists with per-customer overrides. No catalog connector exists and none will; it is theirs.

Day 1. The engineer works with the distributor's developer who owns the service: authentication, the endpoints that matter, how overrides are expressed, what "changed since" means to the service (it has a modified timestamp, which is enough for incremental reads).

Days 2 to 3. The connector: token authentication with refresh, incremental reads on the timestamp with an overlap window, the nested price list flattened into two typed tables (price lists and overrides), rate-limit handling, and recorded responses for the test suite.

Day 4. Packaging as a versioned extension, the compatibility check against the current release, and installation on the distributor's development environment. The first pipeline using it, a daily load of current prices into the warehouse, is built as a verified build.

Day 5. Review with the developer who owns the service and handover: the mapping document, the tests, the package, and the note that the connector is theirs.

Price: the standard custom connector package at $499, plus a verified build at $149 for the first pipeline. The connector is then maintained on the upgrade path.

When custom stops being custom

Two rules decide it:

• Seen twice, it becomes a template or a catalog connector. If a second customer needs the same system, the connector moves from the services column into the product, and the first customer's version is retired onto it at the next upgrade.
• Seen often, it becomes core. A capability that many customers need, such as a new kind of authentication or a data-quality check, is built into the product and arrives for everyone.

This is how the connector catalog grew to the 66 systems it covers today, 57 of them in the open-source build, and it is how it will keep growing: from real systems at real customers, not from a list of logos.

What this is not

It is not general software development. The work stays on the data and AI stack around our products. It is not a change to the product core, ever; if a need cannot be met by an extension, configuration or a service deliverable, it is logged as a product gap, and we tell you so rather than forking. And a custom connector is supported as an extension, with its own stated policy, not as a core feature.

See how we deliver and the integrations catalog.

Frequently asked questions

How long does a custom connector take?

About a week for a bounded REST, SQL or file interface, including tests, packaging and handover. CDC, non-standard signing or multi-system workflows take longer and are quoted.

Does a custom connector break on upgrade?

No. It is built on published extension interfaces and compatibility-checked against each release as part of the normal upgrade path.

Who owns the connector?

You do. It is delivered as a versioned package with its tests and documentation.

Will Revoluzen build a connector for any system?

For any system with a bounded interface on the data and AI stack. We say no to general custom software development, and we say so before quoting.

What does a custom connector cost?

$499 for a bounded REST, SQL or file interface, verified and packaged. Complex cases start at $1,499 and are quoted after a short look at the interface.