JSONBuddy Core API v1 · XML access

Check, format, and verify XML through one contract.

Use three focused XML operations with API-key authentication and predictable JSON responses. Each operation stays deliberately bounded.

Request
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.xml

Contract-bounded operations

Choose the operation that matches the task.

POST /api/xml/check

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.

POST /api/xml/format

Format XML deterministically

Return consistently formatted UTF-8 XML for supported input.

Boundary: namespace-correct signed XML is refused because formatting could invalidate the signature.

POST /api/xml/verify

Verify the safe signature profile

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

Start with the live contract.

  1. Choose the XML operation.
    Match well-formedness, formatting, or restricted verification to the task.
  2. Use the X-Api-Key header.
    Follow the operation-specific authentication and size requirements in Swagger.
  3. Handle the documented response.
    Treat completed checks and transport failures according to the operation contract.
Need schema validation? Use XML ValidatorBuddy Desktop or the ValBuddy CLI for XSD, DTD, and Schematron workflows.

Integrate XML operations without blurring their boundaries.

Use the live Swagger contract as the source of truth.

Open Swagger

Integration guide

Send XML as the request body

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.

Interpret a completed check separately from a transport failure

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.

Format only when changing layout is safe

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.

Keep restricted signature verification within its profile

/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.

Build a predictable client workflow

  1. Choose exactly one of the three documented XML operations.
  2. Read its current request and response schema in Swagger.
  3. Load the API key from protected runtime configuration.
  4. Send the original XML using the documented content type.
  5. Record the HTTP status and parse the JSON response.
  6. Keep operation diagnostics with the input identifier used by your application.
  7. Route schema validation, signing, trust, or unsupported signature work to the appropriate Desktop or CLI workflow.