Check well-formedness
Parse XML securely and return document metadata and native diagnostics. Malformed XML is a completed check with wellFormed: false.
Boundary: no XSD, DTD, or Schematron validation.
JSONBuddy Core API v1 · XML access
Use three focused XML operations with API-key authentication and predictable JSON responses. Each operation stays deliberately bounded.
curl -X POST \
"https://api.json-buddy.com/api/xml/check" \
-H "X-Api-Key: $XML_API_KEY" \
-H "Content-Type: application/xml" \
--data-binary @document.xmlContract-bounded operations
Parse XML securely and return document metadata and native diagnostics. Malformed XML is a completed check with wellFormed: false.
Boundary: no XSD, DTD, or Schematron validation.
Return consistently formatted UTF-8 XML for supported input.
Boundary: namespace-correct signed XML is refused because formatting could invalidate the signature.
Verify integrity for the documented whole-document enveloped xmlvalidator-safe-rsa-sha256-v2 profile.
Boundary: no signing, certificate trust, signer identity, chain validation, external references, arbitrary fragments, or general XMLDSIG.
Integration path
Use the live Swagger contract as the source of truth.
Integration guide
Each XML operation is an HTTP POST request. Supply the API key in the X-Api-Key header, select the operation path from the Swagger contract, and send the XML document using the media type documented for that operation. Keep credentials outside source files and logs. A client should also apply its own connection timeout and treat the HTTP status and JSON response as separate signals.
The contract is the authority for request size, accepted content types, response fields, and error status codes. Recheck it when generating a client or changing an integration. The examples on this page explain the workflow, but they do not replace the current OpenAPI definition.
For /api/xml/check, malformed XML can be a successfully completed API operation whose result says that the document is not well formed. That differs from authentication failure, an unsupported request, a size limit, or a service error. Preserve both the HTTP result and the returned diagnostics so an automated workflow can distinguish bad XML from a request that never completed.
The check operation parses XML and reports well-formedness. It does not validate against XSD, DTD, or Schematron. Route those tasks to XML ValidatorBuddy Desktop or ValBuddy CLI, where the grammar and validation result remain part of the local workflow.
The formatting operation returns consistently formatted XML for supported input. Treat that output as a new representation and decide explicitly whether it should replace, accompany, or be compared with the original. If whitespace is meaningful to a downstream process, test the formatted result in that context before adopting it.
Signed XML requires additional care. Namespace-correct signed input is refused where formatting could invalidate the signature. Do not use the formatter as a preparation or repair step for a signed document; preserve the original bytes and choose a signature-aware workflow.
/api/xml/verify verifies integrity only for the documented whole-document enveloped xmlvalidator-safe-rsa-sha256-v2 profile. A successful result does not establish certificate trust, signer identity, chain validity, business authorization, or long-term signature status. The operation does not sign XML and does not provide a general XMLDSIG engine.
External references, arbitrary fragments, unsupported transforms, and other signature shapes remain outside this API boundary. Use XML ValidatorBuddy Desktop or ValBuddy CLI when a broader supported product workflow is required, and evaluate trust in the security context that owns the relevant certificate policy.