Salesforce SOAP API Testing
Salesforce SOAP API testing validates the XML integrations built on the enterprise and partner WSDLs — the strongly typed contracts many ERP connectors, legacy middleware and long-lived enterprise systems still depend on. It checks session handling, per-record SaveResult errors, SOAP faults and behavior after metadata or API version changes. SyntraFlow is designed to exercise SOAP calls directly and confirm what actually persisted in the org.
SOAP API validation is available for demonstration and proof-of-concept validation against your org and WSDL-based integrations.
Why SOAP integrations need their own tests
SOAP integrations tend to be the oldest and most business-critical connections into Salesforce. They were often generated from a WSDL years ago, compiled into Java or .NET client stubs, and left running. Because the contract is typed and compiled, they are stable until something changes underneath them — and then they break in ways a REST client would tolerate.
The enterprise WSDL is generated for a specific org and reflects its custom objects and fields at the moment it was downloaded. Add a required field, change a field type or delete a picklist value, and a client built on the old WSDL may fail to deserialize a response or send a record the org now rejects. The partner WSDL avoids that by using a generic sObject, but moves type safety into the client code, where a misspelled field name only fails at runtime.
This page covers SOAP-based record integrations and outbound messages. For JSON integrations, see Salesforce REST API testing; for the full API picture, see the Salesforce API testing hub.
Enterprise WSDL versus partner WSDL
The WSDL an integration was built on determines which changes will break it, so tests should target the right risks.
| Aspect | Enterprise WSDL | Partner WSDL |
|---|---|---|
| Typing | Strongly typed to the org's objects and fields | Loosely typed generic sObject with field name and value pairs |
| Scope | One specific org configuration | Any org, used by ISVs and multi-org tools |
| Breaks when | Org metadata changes and the client is not regenerated | Client code references a field that was renamed or removed |
| What to validate | Stubs still deserialize responses after each release | Field names and types resolved at runtime are correct |
| Regression trigger | Any deployment touching integrated objects | Any change to fields the client reads or writes |
A SOAP API test, call by call
SyntraFlow can be configured to follow the same call sequence a SOAP client uses and assert on each envelope.
Establish the session
The test obtains a session through the mechanism the integration uses — ideally an OAuth access token passed in the SessionHeader — and confirms the returned server URL and session are used for subsequent calls.
Send a typed request
create, update, upsert, delete or query calls are issued with controlled data, including optional headers such as AllOrNoneHeader, AssignmentRuleHeader or DuplicateRuleHeader where the integration sets them.
Check each SaveResult or UpsertResult
SOAP DML returns one result per record with a success flag and an errors array. The test asserts every element, so one failed record in a call of 200 is not hidden by the others.
Assert faults precisely
Invalid requests must return the expected SOAP fault — INVALID_FIELD, INVALID_TYPE, MALFORMED_QUERY or INVALID_SESSION_ID — with the fault code the client is written to handle.
Page through query results
query and queryMore are exercised with the QueryOptions batch size the client uses, confirming the QueryLocator is followed until done is true.
Verify persisted data
A follow-up query confirms records after triggers and Flows ran, proving the SOAP call changed the org as intended.
SOAP-specific failure modes
These defects are common in long-lived SOAP integrations and are easy to miss without targeted tests.
Stale enterprise WSDL
The client was generated before a field became required or changed type, so creates fail or responses cannot be parsed after a routine deployment.
Ignored per-record errors
The client checks that the call returned without a fault and never inspects individual SaveResult errors, so rejected records are silently lost.
Session expiry mid-run
Long batch runs outlive the session timeout and start receiving INVALID_SESSION_ID faults, and the client does not re-authenticate.
Username-password login dependency
Integrations that call login() with a stored password are exposed to password policies, MFA changes and Salesforce's move toward OAuth-based authentication.
Pinned old API version
The endpoint URL embeds an API version that Salesforce has scheduled for retirement, and the integration stops working when that version is removed.
Implicit header behavior
Missing or changed headers alter outcomes — assignment rules not firing, duplicate rules blocking saves, or partial commits when AllOrNoneHeader was expected.
Outbound messages: SOAP in the other direction
Outbound messages send SOAP notifications from Salesforce to an external listener, and they have their own behavior to verify.
- The message fires from the configured Flow or workflow rule on the right record changes, and not on changes that should be ignored.
- The listener returns an acknowledgment of true, otherwise Salesforce keeps the message in the queue and retries it.
- Retries continue with increasing intervals for up to 24 hours, so the listener must handle the same notification arriving more than once without creating duplicates.
- The notification includes the fields the listener expects, and a removed field in the outbound message definition is caught before the receiver fails.
- The session ID included for callback, where used, belongs to a user with only the access the listener needs.
- Failed and pending deliveries are visible in the outbound message queue in Setup, and the team knows how to reprocess them — see integration error and recovery testing.
Regression after releases and deployments
The most valuable time to run SOAP tests is right after something changes: a deployment that touches integrated objects, a seasonal Salesforce release, or a planned API version upgrade. A short suite of create, update, query and fault scenarios against each integrated object catches WSDL drift before the enterprise system that depends on it starts failing overnight.
SyntraFlow is designed to run these checks as part of a pipeline, alongside deployment validation, and to repeat them in a preview sandbox as part of seasonal release readiness. Because many SOAP clients are ERP connectors, the same scenario can continue into the connected system to confirm the business record arrived — the approach described on the Salesforce–SAP integration testing page.
Note that the Metadata API and Tooling API also use SOAP, but they manage configuration rather than business data. This page focuses on data integrations; metadata changes are covered under metadata intelligence.
SOAP scenarios and what each proves
A compact regression suite that covers the behaviors SOAP clients most often get wrong.
| Scenario | What it proves |
|---|---|
| Create 200 records with one invalid | The client reads every SaveResult and reports the single failure |
| Same call with AllOrNoneHeader | The whole call rolls back when one record fails, as the client expects |
| Upsert on external ID | Matching records update, new ones insert, and ambiguous matches are errors |
| Query beyond one batch | queryMore is followed until all rows are retrieved |
| Expired session | The client re-authenticates and resumes without duplicating work |
| Field removed from the org | The failure is detected in test, not in the enterprise client in production |
Related pages
Salesforce API Testing
The parent hub comparing REST, SOAP and Bulk API validation.
Salesforce REST API Testing
JSON-based inbound calls and outbound callouts.
Salesforce Bulk API Testing
High-volume asynchronous loads and extracts.
Salesforce–SAP Integration Testing
Validate the ERP end of long-lived enterprise integrations.
Deployment Validation
Catch WSDL-breaking metadata changes before they reach production.
Seasonal Release Readiness
Rerun SOAP regression in preview sandboxes before each release.
SOAP API Testing testing FAQs
What is Salesforce SOAP API testing?
Salesforce SOAP API testing validates XML integrations built on the enterprise or partner WSDL. It checks session handling, per-record SaveResult errors, SOAP faults, query paging and the records that persisted. It is especially important for long-lived ERP and middleware connectors that break when org metadata or API versions change.
Should an integration use the enterprise or partner WSDL?
The enterprise WSDL suits a single org where strong typing is valuable, but it must be regenerated and the client rebuilt when integrated metadata changes. The partner WSDL suits tools that work across orgs. Testing should focus on the risk each carries: stale stubs for enterprise, runtime field errors for partner.
Why do SOAP calls succeed while records fail?
SOAP DML calls return a result for each record in the request. The call itself completes without a fault, but individual records can fail validation or triggers and report errors in their result. A client that does not inspect each result silently drops those records, which is exactly what a test should catch.
Are outbound messages part of SOAP API testing?
They are closely related. Outbound messages are SOAP notifications Salesforce sends to an external listener, with automatic retries for up to 24 hours until the listener acknowledges. Tests confirm they fire on the right changes, carry the expected fields and do not create duplicates when retried.
How do API version retirements affect SOAP integrations?
SOAP endpoint URLs include an API version, and Salesforce retires old versions over time. Integrations pinned to a retiring version stop working when it is removed. Running the SOAP suite against a newer version, and regenerating the WSDL where needed, confirms the upgrade before the deadline.
Can SyntraFlow test SOAP integrations without the original client?
SyntraFlow is designed to issue SOAP calls directly using the same operations and headers the client uses, and to assert on results, faults and persisted data. That lets teams validate contract behavior independently of the enterprise client. Coverage is confirmed during a proof of concept.
Keep legacy SOAP integrations working
See how SyntraFlow is designed to validate WSDL-based calls, faults and outbound messages after every release and deployment.