The connector you need isn’t on the list. Build it anyway.

Every integration project eventually meets the same wall: the platform supports 400 apps, and the one your business runs on — a legacy ERP, an in-house service, a regional payment processor, a partner’s API — is not one of them. The usual answers are all bad: file a request and wait a quarter, pay for a professional-services bolt-on, or quietly drop the requirement. None of those should decide your architecture.

The connector catalog is a constraint you didn’t choose

A fixed catalog is a vendor’s convenience, not a law of nature. It exists because maintaining hundreds of connectors is expensive, so platforms ship the ones with the largest addressable market and leave the long tail to you. That’s a reasonable business decision for them — and a real problem for you, because the systems that differentiate your business are exactly the ones least likely to be on a generic list.

The moment your integration strategy is bounded by someone else’s catalog, you’re optimizing for their roadmap instead of your operations.

Building a connector is a solved problem — with the right engineering

A connector is not magic. Underneath, almost every one is the same well-understood set of concerns, and a senior integration team handles them as a matter of course:

• OAuth2 token refresh and secure, least-privilege credential storage.
• Pagination — cursor, offset, or link-style — so a sync pulls every record, not the first page.
• Rate-limit and retry handling with backoff, so a busy upstream doesn’t drop data on the floor.
• Idempotent writes — insert vs. upsert on a stable external key — so re-runs don’t create duplicates.
• Graceful handling of schema drift and partial failures.

Get those right once, behind a clean contract, and adding a new system becomes configuration over a proven transport rather than a research project.

Build for it once, reuse it forever

The economics flip when connectors are an engineering capability instead of a catalog you’re renting. The first time a client needs a given system, we build the connector to spec; every client after that inherits it. Demand pulls the work, and the library compounds — without anyone paying to speculatively maintain a thousand integrations they’ll never use.

This is exactly the model behind Weldforge, our integration-as-a-service product: a reusable framework for the hard parts, the common systems ready out of the box, and anything else built on the fly when a customer’s spec calls for it — covered by a flat fee, not a per-connector upcharge.

If your roadmap is being held hostage by a connector that “isn’t supported yet,” that’s a solvable problem. Let’s talk.