Connector Validation: Why Testing Is Now the Hard Part of Enterprise Integrations

Here is a pattern we keep seeing in 2026. A B2B SaaS company closes its first enterprise deal. The contract has one technical condition: the product has to talk to the customer’s NetSuite. An engineer sits down with Claude and, three days later, has a connector — the piece of integration code that links your product to a customer’s system. Login works, paging works, the field mappings look right, the tests are green. The demo goes fine.

Then the connector meets the customer’s actual system. A custom field their admin made mandatory in 2019 rejects every record. A script fires on save and rewrites a value the connector depends on. Orders land in a subsidiary nobody mentioned. The integration that took three days to write takes six weeks to fix, and the account team spends those six weeks apologizing.

Two years ago, the slow part of that story would have been writing the connector. Today the writing is fast and the trust is slow. This article is about that flip: why testing has replaced coding as the bottleneck, what validating a connector against a real system involves, and how to handle the part no sandbox can copy, which is the customer’s own setup.

Why is testing now the hard part of shipping an enterprise connector?

Testing is now the hard part because AI tools have made connector code cheap to write, while proving that code against a real enterprise system has stayed as slow as ever. The bottleneck moved from writing to proving.

For most of the past decade, the effort sat in the writing: reading API docs, getting authentication to work, handling paging and rate limits, mapping fields between two systems that disagree about what a “customer” is. That work is now largely automated. A good engineer with a current AI model produces it in days.

Three things did not get cheaper:

• Access to a realistic system to test against. Enterprise vendors do not hand out configured sandboxes on a signup form. When our team built its first reusable SAP S/4HANA connector, getting sandbox access took five weeks. Building the connector took three days, and validating it took two more. The reason your MCP deal stalls isn’t the code. It’s getting a sandbox.
• Knowledge of how a specific customer set up that system. No amount of code quality tells you that this customer’s approval workflow holds every purchase order above a certain amount.
• Safe write testing. You cannot rehearse posting invoices on production. You need somewhere real but consequence-free.

If you still budget integration projects the way you did in 2023, mostly for development, the estimate is wrong twice over: too much for code, too little for proof.

Can AI tools like Claude really build most of a connector now?

Yes, and pretending otherwise would be dishonest. A current model produces working auth flows, paging, retries, field mappings, and MCP tool definitions straight from API docs, and the quality is genuinely good. We build connectors and MCP servers for a living, use these tools every day, and they have made the code-writing part several times faster.

The limit sits somewhere else: the information a connector needs before you can trust it does not exist in any training data. A model can know everything public about NetSuite’s API and still know nothing about the four custom fields your customer’s admin made mandatory, or the script that fires every time a record is saved. Those facts live in exactly one place: that customer’s system.

The missing piece is data, not intelligence. The setup information is private, different for every customer, and often not written down anywhere; the admin who created the rule may have left years ago. A better model next year will not close that gap.

So let AI write the connector, then treat the result like code from a skilled contractor who has never seen the customer’s system. The code is probably fine. The assumptions are unchecked, and checking them happens against a real system, not in a code editor.

Why does the same ERP behave differently at every customer?

The same ERP behaves differently at every customer because ERPs and CRMs are platforms, not finished products. Each company shapes its own copy with custom fields, validation rules, workflows, scripts, and permissions. A connector proven on one instance has not been proven on the next.

The vendor’s API documentation describes the platform. Your customer runs a configuration. The gap between the two is where connectors fail:

• SAP S/4HANA and ECC systems carry custom fields and validations added over many years. A field the docs call optional is mandatory in this company’s postings, and the error message will not tell you why.
• Salesforce admins add validation rules, required fields, and automations that run on every change. Two Salesforce orgs can accept completely different data for the same object.
• NetSuite runs server-side scripts on record events. Your write can succeed and still produce a different record than the one you sent.
• Oracle Fusion, Workday, and Coupa gate everything behind roles and permissions, so the same call works for one integration user and quietly returns partial data for another.

Age makes it worse. A five-year-old cloud CRM at a mid-market company is usually close to standard. A fifteen-year-old ERP at a manufacturer has been bent around every process exception the business ever made, and the people who made some of those changes are gone. These older, heavily customized systems are exactly where enterprise deals live.

The uncomfortable conclusion: “our connector works” only ever describes a connector plus a specific instance, never the connector alone.

Why don’t mocked tests and code review catch what breaks in production?

Mocked tests and code review miss production failures because mocks repeat the same assumptions as the code, and review checks that the code matches the spec. Neither checks that the spec matches the customer’s system.

A unit test with a mocked API response proves your code handles the response you imagined. It says nothing about:

• Real error shapes. Enterprise APIs return errors their own docs get wrong: HTML where JSON was promised, a success status wrapping a failure message.
• Auth over time. Tokens that expire mid-batch, session limits that only bite under load.
• Timing. A record that is created but not yet queryable, which breaks any connector that writes and immediately reads back.
• Silent permission gaps. Field-level security that drops data from responses without an error, so your connector stores empty values where data exists but is hidden.
• Rate limits as actually enforced, which often differ from the documented ones.

There is also a security angle. Astrix Security analyzed more than 5,200 open-source MCP servers and found 88% need credentials, 53% rely on static API keys, and only 8.5% use OAuth. Endor Labs found 82% of the MCP servers they examined using file operations prone to path traversal, and 67% using APIs associated with code injection. In just the first two months of 2026, security researchers filed more than thirty CVEs against MCP servers, clients, and infrastructure. Most of that code passed someone’s review. Code that looks done is not the same as code that is safe in production.

None of this is an argument against unit tests or review. Keep both. They verify your logic, and the open question in an enterprise integration is almost never your logic.

What makes write operations the riskiest part of a connector?

Write operations are the riskiest part because reads fail loudly and cheaply while writes fail quietly and expensively. A broken read returns an error you can see. A broken write creates a purchase order, posts an invoice, or changes a customer record that someone now has to find and undo.

Three things make writes harder to validate than reads:

Writes have chains. Creating a sales order is not one call. The connector has to find the customer, check the item exists in the right subsidiary, confirm a referenced order is still open, and only then commit. Get the order wrong and you create records that look valid one by one and make no sense together. The right chain differs per instance.

Writes trigger side effects. Approval workflows, notifications, and server-side scripts all fire on writes. A test write on a configured system shows you the blast radius. A mock shows you nothing, because the mock does not contain the workflow.

Some writes need a human in the loop by design. For irreversible or high-value actions, the right pattern is two steps: the connector stages the action, shows a person what is about to happen, and commits after confirmation. Where that gate belongs depends on the customer’s risk tolerance, which is exactly the judgment an AI code generator cannot make from docs. We wrote about these guardrails in How to Design MCP Tools Your AI Agent Won’t Misuse.

In our validation work, write paths produce most of the serious findings, and the typical one is rarely a crash. It is a write that succeeds with the wrong result: an invoice posted to the wrong ledger, a record saved without the approval the auditors assume is mandatory. You find those by doing the writes somewhere real and checking what happened inside the system.

What does a connector validation pass actually check?

A connector validation pass runs the connector against a live, configured system and checks five things the code alone cannot prove:

1. Authentication under real conditions. Token refresh over long sessions, expiry mid-operation, behavior under parallel connections.
2. Read correctness. Do queries return what the system actually contains, custom fields included? Does paging survive real data volumes? Do permissions hide data silently?
3. Write safety. Do writes create the intended record and nothing else? Which workflows and scripts fire? Are the chains in the right order?
4. Failure behavior. What does the connector do with real errors, timeouts, rate limits, and a batch that dies halfway?
5. Configuration sensitivity. Which of the connector’s assumptions are really per-instance settings, and what happens at the next customer whose admin chose differently?

This is why we keep our own sandbox environments for the biggest enterprise systems: SAP S/4HANA (cloud and on-prem), SAP ECC, Oracle Fusion, NetSuite, Microsoft Dynamics 365, Workday, Coupa, Salesforce, ServiceNow, and a list that grows week by week. These are real, configured instances, so validation starts on day one instead of after a five-week wait for access.

In our S/4HANA MCP server engagement, the core server plus the first three tools went from start to validated in five working days, with each added tool taking about two more. The client’s own pre-code estimate had been four to six weeks. The difference came from the environment already existing: every day was a build-and-test day instead of a wait-for-access day.

How do you catch problems in a customer setup you have never seen?

You catch them by building the connector to learn each customer’s setup before it writes anything, and by testing the rollout against the customer’s own environment before go-live. A sandbox proves the platform; the connector itself has to handle the configuration.

First, honesty about what a sandbox can do. Our environments catch platform-level defects, which is where most findings live: real error formats, auth behavior, API quirks, write mechanics. What no sandbox can contain is your customer’s specific configuration; that exists in exactly one place. The rest of the answer is how the connector is built, and this is where most of what Inovaflow has learned across 100+ deployments shows up:

Read before you write. A well-built write tool does not fire blind. It first runs a few read calls against the instance it is talking to: pull the field list, check which fields are mandatory, find the approval thresholds. Then it shapes the write to what this instance expects. The connector learns the setup at runtime instead of assuming it at build time.

Rehearse the write. Where the ERP offers a validation or simulation call, use it before the real one. Where it does not, stage the action: create the record in a draft state, or show a person exactly what is about to be committed and wait for a yes. The first real write should never be a surprise.

Remember what you learn. Discovery is wasted if the connector forgets it after every call. A good connector saves what it found about each customer: the custom fields, the rules it hit, the errors it saw. That per-customer profile makes the next call faster and turns a defect found once into a defect fixed for good. If you ship one connector to many customers, this profile becomes the most valuable data your integration produces.

MCP makes this easier than a classic API integration. An MCP server exposes reads and writes as separate tools, and the AI agent calling them can run the discovery reads first and adjust, at runtime, per customer. A hard-coded API integration bakes its assumptions in when it is written. It can still discover and adapt, but someone has to hand-build that logic, which is the part that gets skipped under deadline pressure.

When a break is unavoidable, make the error do the talking. Some first-contact failures cannot be prevented, especially on a heavily customized system. What you can control is what each failure costs. An error that says “field X on record Y was rejected by validation rule Z” turns a week of debugging into an hour of fixing. Vague errors are how a two-day fix becomes a six-week escalation.

Test against the customer’s own environment before go-live. For enterprise rollouts we offer this as a separate step: before your customer switches the connector on, we analyze their setup and run the connector against their sandbox, hunting for exactly the defects this article describes. After years of doing this on enterprise systems, the team knows where the hidden ones usually sit: mandatory custom fields, approval workflows, permission gaps, closed posting periods.

Should you have the connector built, or bring your own for validation?

Bring your own connector if you already have working code; have it built end to end if the system is unfamiliar or you would rather spend your engineers elsewhere. Both paths end with the same deliverable: a connector with evidence behind it.

A few honest notes on choosing. If your engineers built the connector and it is their first contact with the target system, validation will surface findings; budget for a fix cycle, not a rubber stamp. If the target is an older on-prem system with heavy customization, expect the enterprise end of the cost range. If the connector was AI-generated, say so upfront; it changes nothing about the price and helps the validation focus where AI code concentrates its risk. For SAP specifically, our guide to SAP integration services covers what makes that ecosystem its own discipline.

Scoping takes one to two days, and a quote follows within 48 hours of seeing the API documentation. Inovaflow’s enterprise-systems depth comes from the team’s prior careers, including years of ERP integration delivery at Rossum, where the same lesson repeated across projects: an integration is done when the customer’s system says it is done, not when the code review does.