Work through common JSON syntax errors with a small example, then distinguish valid syntax from a valid API request.
An API rejects your request, or a configuration file refuses to load. Before changing the service settings, check whether the document is valid JSON. A missing quotation mark can make an otherwise sensible request unreadable.
Start with a small example
This object is valid JSON:
{"name": "Workshop", "places": 12, "active": true}Property names and text strings use double quotes. Numbers and boolean values do not need them. An extra comma after the final property would make this example invalid. JSON also does not use ordinary JavaScript comments. These syntax distinctions are documented in MDN's JSON reference.
Validate before debugging the integration
- Copy a non-sensitive example of the document.
- Open the JSON validator and beautifier.
- Run the input and inspect any syntax error.
- Fix one issue at a time, keeping the intended values unchanged.
- Review the formatted structure before using it in your integration.
Watch for smart quotation marks introduced by a word processor, missing separators and brackets that do not close. Formatting can make nesting easier to follow, but it cannot decide which data your application intended.
Valid JSON is only the first check
An API may require places to be a number rather than the string "12". It may also require fields missing from this example. Compare your document with the receiving service's schema and documentation after the syntax is fixed.
Do not paste production secrets or private customer records into a public utility. Replace them with representative sample values when investigating structure.
Try the validator with the example above. For a broader workflow, browse useful everyday tools, or create a r37dy account when you need to manage the links around your project.