We needed to build an automated job that publishes vehicle inventory to Google Merchant Center. Should have been straightforward. But it wasn't.

The documentation for Google Merchant Center was extensive, but some critical information wasn't straightforward at all. For example, where exactly to place the cost field. The documentation about mileage for new versus pre-owned vehicles wasn't clear either. Mileage isn't applicable for new vehicles, but if the mileage was above a certain threshold, the vehicle would be considered pre-owned and shouldn't be flagged as new. Examples like this weren't spelled out clearly, and it took us considerable time to understand and implement correctly. Several weeks passed before we finally got it working.

We spent days understanding their structure. What they called a field versus what we called it. Which fields were required, which were optional, what format they expected. We mapped our dealership data to their schema, field by field. We submitted a test payload and got back validation errors. We fixed those, found more errors, and iterated again.

This is normal. We accept this as the cost of integration. Two systems need to talk, so someone has to build the bridge. That someone is usually a developer spending days becoming an expert in someone else's system just to send their own data. In an ideal situation, the developer would document all their findings, but that usually doesn't happen. The developer leaves, and we're left with technical debt, wondering how any of this worked.

But what if it doesn't have to be?

Then We Tried Something Different

A few months later, we tackled a different problem. We wanted a way to extract information from automotive service repair orders by OCRing the documents. This was for an application we built to allow customers to pay their repair orders online. We wanted the service advisor to be able to pre-populate information from the document rather than manually entering everything. We needed to extract structured data from these documents: customer name, RO number, VIN, contact information, line items, total due—the usual suspects.

So we tried something simple. We OCRed the documents and fed the text to the OpenAI API with a straightforward prompt. Below is a snippet of the prompt.

You are an extraction assistant that will be provided the last page of a repair order invoice. 
Please extract the following data from that invoice: RO Number, VIN code, customer name, customer e-mail address, customer phone number, tag number, stock number, due amount. 
The result is required to be received as a JSON with the following keys:
	- ro_number (string)
	- vin (string)
	- customer_name (string)
	- customer_email (string)
	- tag_number (string)
	- stock_number (string)
	- amount_due (number)
	- phone (string)
...

After a few attempts adjusting the prompt, it worked perfectly. It was amazing how easy it was. No schema definition beyond what you see above. No complex field mapping logic. No contract negotiation with the repair order "API." Just a clear description of intent and the structure we wanted back.

We didn't spend days learning a formal structure. We just described what we wanted, and the AI figured it out. Repair order documents are fairly standard across dealerships, but we didn't teach the AI the format. It figured it out on its own.

That's when the question hit me.

We spent weeks configuring Google's API because we had to learn their exact contract. But when we needed structure from an unknown source, we just described what we wanted and it worked.

If AI can interpret a scanned document, why can't it interpret API payloads?

The Current State of API Integration

APIs work the way they do for good reasons. Strict contracts prevent ambiguity. Both sides agree on structure upfront, and the communication becomes predictable, deterministic, testable. When you send a POST request with specific fields, you know exactly what you'll get back.

This works until it doesn't.

Version drift is the obvious problem. The API provider updates their schema, but your code doesn't know about it yet. Something breaks, and you scramble to fix it. If you're lucky, they versioned their API properly and gave you a deprecation window. If you're not, you find out when production goes down.

Then there's the schema mismatch problem. Your mental model of the data doesn't match theirs. You think of it as "vehicle inventory." They think of it as "product catalog with automotive attributes." You have to translate your thinking into their structure, and every single integration becomes a translation exercise.

The real cost isn't the initial setup. It's the ongoing cognitive overhead. You're not just maintaining your system, you're maintaining a mental map of every external system you integrate with. How they structure data, what they call things, what their validation rules are. That map lives in your head, or scattered across documentation, or buried in code comments.

The current workarounds don't really solve this. Middleware layers just move the translation work to a different place. ETL tools make it easier to configure, but you're still doing the configuration. Zapier and similar platforms give you a UI for mapping fields, which is better than code, but you're still manually telling System A how to speak to System B.

I had a client who decided to create an entire back-end job using .NET programmatically. I asked if he considered using an ETL tool to configure the background job for data syncing. He said the reason he didn't go that route is only one author could own an ETL configuration. However, programming it in code could have multiple people work on it. Not sure if I agree with that statement, but I do see his point where an ETL configuration is authored by one person while programming could be done by multiple developers. At the end, the knowledge lives and dies with the author.

We just deal with it. It's the tax we pay for building integrated systems.

What If AI Sat in the Middle?

Here's what I keep thinking about: not replacing APIs, not bypassing validation, but creating an adaptive translation layer.

Imagine you're integrating with a new system. Today, you spend hours or days reading their documentation, understanding their schema, writing mapping code. What if instead, you described your intent and the AI proposed the mapping?

"I have vehicle inventory data. I need to send it to Google Merchant Center."

The AI examines both schemas. It sees you have "make" and "model" fields. It sees Google wants "brand" and "mpn." It proposes a mapping. You review it, approve it, and you're done. Hours instead of weeks.

Or consider version drift. System B updates their API. In the traditional approach, your integration breaks and you scramble to fix it. With an AI layer, the AI detects the change, adapts the mapping, and flags breaking changes for your review. You get graceful degradation instead of hard failure.

The repair order problem is a good model for this. The AI didn't need to know the exact location or label of every field. It understood the intent: "Find the total amount owed." Whether that was labeled "Total Due" or "Amount Owed" or "Balance" didn't matter. The AI knew what to look for.

APIs today require exact field names. You have to know if they use "total_due" or "totalDue" or "amount_owed." The AI could handle that variance because it understands semantic meaning, not just syntax.

This isn't about full autonomy but liability issues make that a non-starter. This isn't about replacing contracts but you still need validation and guarantees. And it's definitely not magic. You still need oversight.

But it could be a co-pilot for integration work, something that reduces cognitive load, handles the routine 80% of mapping work, and flags the 20% that needs human judgment. The parts where business logic matters, where edge cases live, where the stakes are high.

Think about it as the difference between writing assembly code and writing Python. You still need to understand what you're building, but the tool handles more of the mechanical work.

Where This Works Today (and Where It Doesn't)

Some tools are already doing pieces of this. Zapier has AI features now, though they still require manual configuration. LLM-powered data mappers are appearing and promising, but not production-ready at scale. AI code assistants help write integration code, reducing some of the manual work.

AI excels at certain types of problems: unstructured to structured data, like our repair order example. Tolerating format variations. Understanding semantic meaning versus exact syntax. These are the areas where the technology is genuinely strong today.

But AI struggles in other areas that matter for production integrations. Deterministic validation is harder where you need to guarantee certain behaviors. Edge cases and error handling require explicit logic. Liability and auditability matter when things go wrong because you need to know why a decision was made. Performance at scale is still a question mark. And security implications are real when you're routing sensitive data through an AI layer.

The gap is that no tool currently owns this space in a production-safe way. Everyone's experimenting. Lots of demos, lots of proof-of-concepts. But no one's shipping this as core infrastructure yet. No one's saying "trust us to mediate all your API integrations in production."

That gap tells you something. Either the technology isn't quite there, or the trust isn't there, or both.

The Hard Questions

Is this inevitable? Maybe. AI capability is advancing, developer pain is real, and the economic incentive exists. Companies would pay to reduce integration time from weeks to hours. But trust and liability remain unsolved. Until someone figures out who's responsible when the AI gets it wrong, adoption will be limited.

Will strict contracts always win? Depends on the context. In regulated industries like finance and healthcare, probably yes. The audit requirements and compliance needs demand explicit contracts. In fast-moving spaces like SaaS integrations, AI might win because speed matters more than perfect guarantees. A hybrid approach seems most likely, where critical paths stay explicitly mapped and routine integrations get AI assistance.

Who owns liability when AI gets it wrong? This might be the real blocker. With traditional APIs, you wrote the mapping code, so if it breaks, you own it. With AI-assisted integration, who's responsible for the interpretation? The AI provider? The developer who approved the mapping? The company using the tool? This isn't just a technical question but it's a legal and business question. Until there's clarity here, enterprises won't bet their production systems on it.

Security implications matter too. An AI layer as a middleman means the AI sees all your data, and that raises questions. Prompt injection risks where malicious payloads could manipulate the AI's behavior. Model poisoning concerns if someone can influence how the AI interprets data. Trust boundaries get blurry when you introduce a non-deterministic layer. These aren't reasons to dismiss the idea. They're reasons to be thoughtful about it.

What I'm Watching For

There are signals this might be happening. API providers are building AI assistants into their documentation, not just static docs, but interactive helpers that understand what you're trying to do. Integration platforms are making AI mapping the default option, not an experimental feature. Insurance and liability products are emerging for AI-mediated integrations. Standards bodies are starting to address AI in integration specifications.

What would make me trust this in production? A few things.

A deterministic validation layer on top of AI interpretation. The AI can propose the mapping, but there needs to be a separate validation step that guarantees correctness. Audit trails showing why the AI made specific mapping decisions, not just "it worked," and "here's the reasoning." Rollback mechanisms when the AI gets it wrong: fast, automated ways to revert to known-good states. And clear liability frameworks, because someone has to own the risk.

The question I keep coming back to is this: we trust AI to interpret messy human documents. Medical records, legal contracts, financial statements where these are high-stakes, unstructured data, and we're increasingly comfortable letting AI make sense of them. Why don't we trust it to interpret structured machine data? Maybe we should. Maybe we shouldn't. But we should at least be asking the question.

Final Thought

I'm not sure if AI is the magic bullet that will build bridges between APIs. Maybe APIs themselves will eventually fade away, replaced by systems that communicate through AI intermediaries, speaking in intent rather than contracts.

The repair order project made me wonder. We solved a harder problem with less effort. The data was messier, the structure was looser, but the AI understood intent, and that was enough.

Integration friction is technically solved. We have APIs, protocols, and standards. But it's not practically solved. We still spend weeks on configuration. We still deal with version drift. We still maintain mental maps of every external system.

The question isn't whether AI can do this. We already know it can interpret unstructured chaos and produce structure. The question is whether we're ready to trust it with the structured communication we've spent decades perfecting.

Maybe we are. Maybe we're not.

But somewhere between a repair order document and a pristine API specification, there's a conversation worth having about what communication between systems should look like.

We've been building bridges the same way for a long time. Perhaps it's time to ask if there's a better way.