Is there an existing issue for this?
Summary
Add a SOAP datasource plugin, structured similarly to the existing REST API plugin, that lets users connect to a SOAP web service via its WSDL, discover available operations, and build actions against them (request construction, SOAP envelope handling, response parsing) the same way the REST plugin handles arbitrary HTTP endpoints today.
Why should this be worked on?
Appsmith currently has strong REST API support but no SOAP support at all - I searched the codebase and found zero references to SOAP or WSDL anywhere in the plugin ecosystem. SOAP is legacy in the broader industry sense, but it's still very much alive in enterprise environments: Oracle E-Business Suite, Oracle ERP Cloud, and a large number of other enterprise systems (billing, insurance, banking, government) still expose SOAP web services as a primary or only integration point, often alongside newer REST APIs on the same system.
Teams trying to use Appsmith to build internal tools/admin panels against these systems currently have no first-class way to do it - they'd need to hand-roll SOAP envelope construction inside a generic REST API datasource (manually setting the right headers, building XML request bodies, parsing XML responses), which defeats the point of a low-code datasource integration and is exactly the kind of friction Appsmith's existing plugins are meant to remove.
I have 15+ years of hands-on experience with exactly these enterprise SOAP integration patterns (Oracle ERP/EBS SOAP web services specifically) and would be glad to scope and build this if there's appetite for it. Wanted to check in on direction/interest before putting together a detailed design (plugin structure, WSDL parsing approach, how it'd mirror the existing REST plugin's datasource form/action config pattern) given the size of this relative to a typical PR.
Is there an existing issue for this?
Summary
Add a SOAP datasource plugin, structured similarly to the existing REST API plugin, that lets users connect to a SOAP web service via its WSDL, discover available operations, and build actions against them (request construction, SOAP envelope handling, response parsing) the same way the REST plugin handles arbitrary HTTP endpoints today.
Why should this be worked on?
Appsmith currently has strong REST API support but no SOAP support at all - I searched the codebase and found zero references to SOAP or WSDL anywhere in the plugin ecosystem. SOAP is legacy in the broader industry sense, but it's still very much alive in enterprise environments: Oracle E-Business Suite, Oracle ERP Cloud, and a large number of other enterprise systems (billing, insurance, banking, government) still expose SOAP web services as a primary or only integration point, often alongside newer REST APIs on the same system.
Teams trying to use Appsmith to build internal tools/admin panels against these systems currently have no first-class way to do it - they'd need to hand-roll SOAP envelope construction inside a generic REST API datasource (manually setting the right headers, building XML request bodies, parsing XML responses), which defeats the point of a low-code datasource integration and is exactly the kind of friction Appsmith's existing plugins are meant to remove.
I have 15+ years of hands-on experience with exactly these enterprise SOAP integration patterns (Oracle ERP/EBS SOAP web services specifically) and would be glad to scope and build this if there's appetite for it. Wanted to check in on direction/interest before putting together a detailed design (plugin structure, WSDL parsing approach, how it'd mirror the existing REST plugin's datasource form/action config pattern) given the size of this relative to a typical PR.