When an AI assistant is enough

If the service has a handful of operations with simple types, you are building a prototype, and you can check the XML on the wire yourself, asking an AI assistant for a client is a reasonable shortcut. Review the result like any other code you didn't write, and test it against the real service.

What a SOAP client has to get exactly right

A SOAP client is a contract with the server. The WSDL and its XML schemas define that contract down to the last detail, and the client has to follow every rule:

• Namespaces. Every element has to be in the right namespace, and elementFormDefault decides whether nested elements are qualified.
• Optional vs. nil. minOccurs="0" means "leave the element out"; nillable="true" means "send it with xsi:nil". Servers treat the two differently.
• Derived types. When an operation expects a base type and you send a subclass, the XML needs an xsi:type attribute — and responses have to be mapped back to the right class.
• Imported schemas. Types often live in separate files, pulled in with xsd:import, xsd:include or wsdl:import.
• SOAP version. SOAP 1.1 and SOAP 1.2 use different envelope namespaces, content types and fault formats.
• Everything else. Enums, dates and durations, arrays, SOAP headers, faults, binary data and MTOM attachments.

Mistakes here usually compile. They show up at runtime — as a fault from the server, or as a field that is silently empty. easyWSDL reads these rules from the WSDL and handles them in the generated code. An AI assistant gets them right only if it sees every schema file and applies every rule consistently across the whole client.

Large WSDLs are where generation pays off

Enterprise WSDLs often have hundreds of types spread across several schema files. To write a correct client, an AI model needs all of those files in its context and has to stay consistent across thousands of lines of output — and someone has to review all of it.

easyWSDL parses the whole service in one pass. Upload a zip with the WSDL and its schema files, or a JSON file that lists several WSDLs — shared types are then generated only once (see the FAQ). Types and operations follow the same conventions throughout the client.

Same WSDL, same classes

Ask an AI assistant for the same client twice and you can get two different implementations: language models don't produce identical output on every run, and the models themselves keep changing. That is fine for a one-off. But SOAP services change over time, and you will regenerate.

easyWSDL is a rule-based generator. With the same WSDL, the same settings and the same generator version, it produces the same classes, names and methods every time — only the licence line in the file headers and the date in the readme differ. Free accounts add a random class prefix on each run; with Premium you choose the prefix, or save your settings and renamed classes as a template.

Regenerate whenever the service changes — on the website, or from Android Studio or IntelliJ with the easyWSDL plugin. The diff in your pull request shows what changed in the service, not what changed in the model.

Your WSDL and AI tools

A WSDL describes a back end: its operations, its data structures and often internal host names. To have an AI assistant write the client, you have to give it that WSDL — so it falls under your organization's rules for AI tools.

easyWSDL doesn't use an AI model. Your WSDL is uploaded to easyWSDL's servers, processed by our code generator, and not sent to any AI service.

Compiled before every release

The generator has an automated regression suite built from real-world WSDLs of production services. Every release build runs it: the suite generates clients in Java, Kotlin, Swift, Objective-C, Dart and TypeScript and compiles them. If the suite fails, the build is not released.

Platforms without a built-in WSDL import

.NET developers have Add Service Reference and dotnet-svcutil. Java has JAX-WS and wsimport — but that code doesn't run on Android. Android Studio, Xcode and Flutter don't ship a WSDL import tool at all. easyWSDL generates native clients for Java and Kotlin (Android), Swift and Objective-C (iOS), Dart (Flutter) and TypeScript.

easyWSDL and your AI assistant, together

You don't have to choose. A workflow that plays to both strengths:

1. Generate the client with easyWSDL — on the website or from Android Studio / IntelliJ.
2. Add the generated code to your project and keep it as generated. Extend it instead of editing it — for example, to add authentication or custom SOAP headers. The tips that come with the generated code and our FAQ show how.
3. Ask your AI assistant to build the features on top: repositories, view models, screens and tests. It works with typed classes and methods instead of raw XML.
4. When the WSDL changes, regenerate with the same template and review the diff.

Tip: tell your assistant that the generated folder is off limits — in CLAUDE.md, .github/copilot-instructions.md or your Cursor rules — so it extends the client instead of rewriting it.

When to use which

Your situation	What we'd use
A few operations, simple types, a quick prototype	An AI assistant can be enough. Review the code and test it against the real service.
Hundreds of types, imported schemas, inheritance	Generate the client with easyWSDL.
The WSDL changes and you regenerate often	easyWSDL with a saved template.
The WSDL describes internal systems	easyWSDL — no AI model sees the WSDL.
App logic, UI and tests around the client	Your AI assistant, on top of the generated code.