XML (Extensible Markup Language)
XML (Extensible Markup Language) is the structured text format Salesforce uses for SOAP API payloads, metadata definitions, package manifests, and several integration endpoints.
Definition
XML (Extensible Markup Language) is the structured text format Salesforce uses for SOAP API payloads, metadata definitions, package manifests, and several integration endpoints. Each XML document is a tree of named tags with attributes and nested content, validated against a schema (XSD or WSDL) that defines the allowed structure. Salesforce ships every metadata file (custom objects, Apex classes, page layouts, profiles) as XML, which is why the Salesforce CLI, change sets, and source-driven development all read and write XML under the hood.
XML in the Salesforce ecosystem appears in three primary places. The first is the Metadata API and Tooling API, which serialize org configuration as XML for retrieval and deployment. The second is the legacy SOAP API, where every request and response is an XML SOAP envelope. The third is integration endpoints that exchange XML payloads with external systems (older ERP, BizTalk, financial systems). Modern Salesforce REST and most new integrations use JSON instead, but XML remains the canonical format for metadata work because Salesforce DX, sfdx-project.json builds, and every package manifest still expect XML files.
Where XML still matters in modern Salesforce development
Metadata API XML
Every piece of Salesforce metadata serializes to XML. A custom object is an .object-meta.xml file with tags for each field, validation rule, and record type. A profile is a .profile-meta.xml file with tags for every object permission, field permission, and tab visibility. An Apex class has a .cls-meta.xml file alongside the .cls source. When the Salesforce CLI pulls metadata from an org, it writes these XML files to disk; when it deploys, it reads them, packages them, and posts to the Metadata API. The schema is documented and stable across releases.
Package manifest (package.xml)
Every metadata deployment uses a package.xml manifest that lists which components to include. The file has a tree of <types> elements, each with a <members> list (component names or wildcards) and a <name> (component type, like CustomObject, ApexClass, Flow). The package.xml is what change sets, sfdx force:source:deploy, and the Ant Migration Tool read to know what to operate on. Writing a precise package.xml is a core skill for any release engineer working in the Salesforce ecosystem.
SOAP API XML envelopes
The Salesforce SOAP API exchanges XML SOAP envelopes. A typical request is a <soap:Envelope> wrapping a <soap:Header> (with the session ID) and a <soap:Body> (with the actual call like <create>, <update>, <query>). Responses follow the same envelope shape. The XML is verbose compared to JSON but the structure is unambiguous and type-safe through the WSDL. Customers with legacy integrations on BizTalk, Mulesoft, and older enterprise integration platforms still maintain SOAP-XML integrations because rewriting them to REST is not worth the migration cost.
XML schema validation through WSDL
Salesforce publishes a WSDL (Web Services Description Language) file that defines the XML schema for the SOAP API. The WSDL declares every method, every input parameter, every output type, and the XML shape of each. Integration developers use the WSDL to generate type-safe client stubs in Java, .NET, or Python that handle XML serialization automatically. The WSDL is updated each release; customers usually generate a stub once and reuse it for years.
XML in inbound and outbound integrations
Beyond the API, Salesforce supports XML payloads in outbound messages (workflow rule actions that POST an XML message to an external endpoint) and inbound webhooks via Apex REST. Outbound messages serialize the triggering record into an XML envelope per the published schema. The external endpoint replies with an acknowledgement XML. This pattern was the dominant Salesforce integration shape from 2005 through 2015 and is still in production at most enterprise customers.
XML vs JSON: when each makes sense
JSON is smaller, easier to parse with modern tooling, and the default for REST APIs. XML is more verbose but has stronger schema enforcement through XSD and richer namespace support. New Salesforce integrations almost always use JSON; legacy integrations stay on XML because the cost of migration outweighs the benefit. Inside Salesforce, metadata is XML because the schema enforcement matters; metadata files are read by the platform deploy engine and must be exactly correct.
Parsing XML in Apex
Apex includes a Dom.Document class for parsing XML strings and walking the tree. Most XML-handling code in Apex serializes outbound messages (constructing the XML envelope), parses inbound webhook bodies (extracting fields from a SOAP-style response), or processes Metadata API responses. The Dom.Document API is straightforward but verbose; for large XML payloads, customers often use the streaming Xmlstreamreader API to avoid loading the entire document into heap memory.
Read and edit a Salesforce metadata XML file
Pull a metadata component from an org as XML, edit the configuration in your editor, and deploy the change back through the Salesforce CLI.
- Retrieve metadata via the CLI
Run sf project retrieve start --metadata CustomObject:Account in your Salesforce DX project. The CLI writes Account.object-meta.xml to the force-app metadata folder.
- Open the XML in your editor
Open Account.object-meta.xml in VS Code. The file is a tree of fields, validation rules, and record types in XML tags.
- Make the change
Edit the relevant tag. Add a new field, change a validation rule formula, update a label. Save.
- Validate the XML
The Salesforce extension flags syntax errors and tag mismatches inline. Fix any red squiggles before deploying.
- Deploy back to the org
Run sf project deploy start --metadata CustomObject:Account. The CLI packages the XML and posts it to the Metadata API. Deploy result lands in seconds.
- Verify in Setup
Open the org in a browser. Setup, Object Manager, Account. Confirm the change you made in XML now appears in the UI.
Salesforce API that exchanges metadata as XML; backs every CLI deploy and retrieve.
Legacy XML-envelope API for record CRUD; still supported alongside REST.
XML schema that describes the SOAP API for type-safe client generation.
Manifest file listing metadata components to include in a deploy or retrieve.
- Metadata XML is strict about tag order and attribute names. A typo or out-of-order tag fails deploy with a vague schema-validation error.
- XML namespaces matter. The xmlns attribute on the root element must be exactly the Salesforce metadata namespace URI; substitute the wrong one and the deploy refuses the file.
- XML payloads are bigger than JSON. SOAP integrations with high message volume can hit network bandwidth or API limits faster than the equivalent REST integration.
- Parsing large XML in Apex eats heap. Use Xmlstreamreader for documents over a few hundred KB; Dom.Document loads the entire tree into memory.
Trust & references
Cross-checked against the following references.
- Metadata API Developer GuideSalesforce Developer Docs
- SOAP API Developer GuideSalesforce Developer Docs
- XML Classes in ApexSalesforce Developer Docs
Straight from the source - Salesforce's reference material on XML (Extensible Markup Language).
- package.xml ManifestSalesforce Developer Docs
- Dom.Document ClassSalesforce Developer Docs
- Xmlstreamreader ClassSalesforce Developer Docs
Hands-on resources to go deeper on XML (Extensible Markup Language).
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is XML used for in Salesforce?
Q2. What file uses XML for deployments?
Q3. REST or SOAP uses XML?
Discussion
Loading discussion…