XML to JSON API

About the XML to JSON API

When you need to change XML to JSON inside an app or pipeline, POST the XML and read back JSON. The XML to JSON API parses the document and returns it as a nested JSON object that mirrors the element tree, with the root element as the top-level key, child elements in order and text content kept alongside them, so you can work with old SOAP responses, RSS feeds, sitemaps or config files using ordinary JSON tooling.

Integration developers use it when a partner, government feed or legacy system only speaks XML but the rest of the stack expects JSON, and in no-code tools where parsing XML by hand is awkward. Badly formed input is reported as an error with the parser's message rather than producing a half-converted object.

There is no plan difference: the Free plan and paid plans run the same conversion and return the same output.

How it works

The xml string is trimmed and must start with < and contain >; anything else is rejected with a 400 before parsing. The document is then converted with the simple-xml-to-json library, and the resulting object is returned directly as data, so its shape depends entirely on your XML rather than on a fixed schema.

The root element becomes the single top-level key. Each element is an object keyed by its tag name. Child elements are listed, in document order, in a children array, where each entry is itself a one-key object such as {"to": {"content": "Tove"}}. An element's text is placed in a content field. Because children are an array of single-key objects rather than a map, repeated tags such as several <item> elements are kept in order and none overwrite each other; iterate children and read each entry's key to find the tag.

If the parser throws, the response is a 400 that includes its message. Documents nested deeply enough to exhaust the parser's recursion return a 400 saying the document is nested too deeply to parse. An empty conversion result is also reported as invalid XML.

What people use it for

Legacy SOAP Integration

When ingesting legacy SOAP web service responses, modern frontend microservices parse the returned XML body into JSON before processing client requests.

RSS Feed Ingestion

News aggregators translate incoming XML syndication feeds into standard JSON records to index articles directly into document databases.

Supply Chain Invoices

To process electronic data interchange documents, logistics platforms convert supplier XML invoices into JSON payloads for internal billing services.

Webhook Payload Normalization

Convert XML notifications from payment gateways and partner APIs into JSON before passing event payloads to serverless event brokers.

Ways to call it

One endpoint, many ways in — REST with JSON, XML, YAML and CSV, plus GraphQL and an MCP interface for AI agents.

JSON

Default REST response

XML

Markup format

YAML

Human-readable

CSV

Tabular export

Beta

GraphQL

Query language

New

MCP

For AI agents

Request parameters — POST /v1/xmltojson

Sent as JSON in the request body. Premium parameters are accepted on every plan but only take effect on plans that include them. Anything not listed here is dropped rather than passed through.

Required

1
2
3
4

curl -X POST "https://api.apiverve.com/v1/xmltojson" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"xml":"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<note>\n  <to>Tove</to>\n  <from>Jani</from>\n  <heading>Reminder</heading>\n  <body>Don'\''t forget me this weekend!</body>\n</note>"}'

Authentication

Send your key in the x-api-key header. That is the only auth step — no token exchange, and no per-endpoint scope to configure.

Response — POST /v1/xmltojson

Every APIVerve endpoint returns the same three top-level keys, so one response handler covers your whole integration: status, error and data. Only data changes shape.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "status": "ok",
  "error": null,
  "data": {
    "note": {
      "children": [
        {
          "to": {
            "content": "Tove"
          }
        },
        {
          "from": {
            "content": "Jani"
          }
        },
        {
          "heading": {
            "content": "Reminder"
          }
        },
        {
          "body": {
            "content": "Don't forget me this weekend!"
          }
        }
      ]
    }
  }
}

Response fields

Paths are relative to data. Premium fields are absent rather than zeroed on plans that do not include them, so check for presence instead of comparing to 0.

Response headers

Every response carries your balance, so your own code always knows where it stands without polling anything. All four are exposed to browsers through CORS.

Errors

Read the HTTP status first, then error for the specific reason. The body names the parameter that has to change.

What a call costs — 1 credits per call

Credits are shared across every APIVerve API — one balance, one key, one bill. Failed requests never count against it, so a rejected input costs nothing.

Calls are what the credits buy at this API's rate — spend them here, on any of the other APIs, or across both. Nothing is reserved per endpoint.

Zero-code embed — one snippet, no backend

Drop an interactive XML to JSON form onto any page. The widget calls the API for you, so no key ever appears in your markup and there is nothing to deploy.

Changelog — XML to JSON API

Every change to this endpoint, newest first. Breaking changes ship as a new version and the previous one keeps serving — response fields are added, never removed or retyped in place, so an integration written against v1 keeps working.

Currently v1