Wrapping a SOAP API in an Afternoon: A Field ROI Story

Here is a Tuesday I actually worked, lightly disguised. A property-management customer runs on Yardi Voyager — a SOAP API, XML envelopes, credentials buried in the body, faults that arrive wrapped inside a cheerful HTTP 200. Their team wanted their agents to answer questions about lease charges and, eventually, to create them. Historically that request meant a scoping call, a two-week integration ticket, and a developer who would spend the first three days just learning where Yardi hides its failures. Instead we wrapped it before lunch. This is the field view — what the day looked like, and what the before-and-after actually saved.

9:15 — the old estimate

The customer's own number for this was "three weeks, one engineer." That is the honest going rate for an arcane API: someone has to reverse-engineer the auth, hand-parse the XML, discover that ImportLeaseCharges doubles as both create and edit depending on whether an <Id> is present, and then wire it into whatever consumer needs it. And critically, that cost is per consumer. The chatbot team pays it. Later the reporting Mission pays it again. The estimate was not wrong; it was just describing a tax that never stops being levied.

10:00 — wrapping it, for real

We opened the Instant MCP builder and started from the Yardi Voyager template — six tools spanning lease charges and documents, lifted from real production envelopes. The SOAP body templates were already wired with {{YARDI_USERNAME}} and the other six credential secrets. Fault detection was pre-filled with <faultstring>(.*?)</faultstring>, so a Yardi error would surface as a real error instead of silently passing garbage to the model. Field extraction on list_lease_charges pulls the <LeaseCharge> blocks out of the 8KB envelope and hands back a clean array.

We set the seven Yardi secrets — encrypted at rest, injected as headers on every call, never visible in the UI again. We pointed the base URL at their Yardi instance. Then we opened the playground and typed a sentence: "List the petrent charges for tenant t0001234 at property 1234." The agent picked list_lease_charges, filled the parameters, fired the SOAP call, and answered in plain English. No envelope authoring. No XML parsing. It was working before 10:30.

11:00 — the part the demo doesn't show

Reading Yardi is nice. The customer's real ambition was writing — letting an agent create a lease charge. That is exactly where most people get nervous about handing a legacy system to an AI, and rightly so. This is where wrapping the API into the StudioX platform rather than a loose script earns its keep.

We built a small Mission with a Lease Ops agent pointed at the wrapped server. When someone asks it to create a charge, the reasoning runs, and the synthesis step — under its human-in-the-loop instruction — does not just fire create_lease_charge. It emits an approval request. The platform turns that into a decision-queue row and emails the property accountant a magic link: approve or reject. The SOAP call that mutates Yardi does not happen until a human clicks approve. Every step is visible on the Explain rail — which tool, which parameters, what came back. Trevor lays out the exact mechanics of that gate in How It Works; in the room, the effect was simply that the customer's controller stopped looking worried.

The ROI, counted honestly

Let me put numbers on it, because "an afternoon instead of three weeks" sounds like marketing until you count it properly.

• First integration: ~3 weeks of one engineer collapsed to about half a day. Call it a 90%-plus reduction on the initial build.
• Every integration after the first: this is the real win. The second consumer — the reporting Mission — cost zero additional integration work. It discovered the same wrapped tools automatically. The old model paid the three-week tax again; the new model paid nothing.
• Maintenance: when Yardi rotated a credential, we updated one encrypted secret in one place. No redeploy, no hunting through eleven codebases. The next tool call used the new value.
• Governance, which is not free anywhere else: one audit trail, one access-control point, one place every call is logged with caller identity and duration. The customer's security team got that as a byproduct instead of a separate project.

A conservative tally for this one customer: the first build saved roughly two-and-a-half engineer-weeks, and each of the three downstream consumers they've since added would each have been another multi-week ticket under the old model. That is the shape of it — the savings compound with every new agent, because the integration is done once and shared.

What changed on the ground

The thing I want field teams to take away is not the speed of the first wrap, impressive as it is. It is that the arcane API stopped being a bottleneck at all. Before, every new use of Yardi was a negotiation with the engineering calendar. After, it is a one-line answer: "it's already wrapped — register the URL." The support bot, the reporting Mission, and the billing agent all consume the same governed tool, and none of them ever had to learn what a <faultstring> is.

If you're staring at your own version of that customer's spreadsheet of arcane APIs, the honest advice is to stop scoping three-week tickets and go wrap one this afternoon. The Instant MCP tooling will surprise you with how little there is to it — and Harry's case for why this matters to the business, not just the engineers, is in Why It Matters.