JSON for Analysts: Read the Payload Fluently

JSON is the format of API payloads, event messages, and config in nearly every modern system. Reading it fluently, objects, arrays, nesting, and types, lets an analyst understand exactly what data is moving through a system without asking a developer to translate.

JSON (JavaScript Object Notation) is a lightweight, text-based format for structured data, built from objects (key-value pairs in curly braces), arrays (ordered lists in square brackets), and values that are strings, numbers, booleans, null, objects, or arrays. It is the most common format for API requests and responses, event messages, and configuration, which means an analyst encounters it constantly, in the API contract, the response you assert in a test, the Kafka event you validate, the config that controls behavior. Reading JSON fluently lets you understand exactly what data a system sends, receives, and stores, which is essential for writing requirements, designing tests, and debugging, without depending on a developer to interpret it. This is foundational developer analyst literacy that underpins almost everything technical an analyst does, and it pairs with HTTP status codes and reading API contracts.

JSON is genuinely simple, which is why it won, and an analyst can become fluent in it in an afternoon. The broader set of practical technical skills it sits within is in The Technical Skills Guide for BAs.

What are the building blocks of JSON?

JSON is built from just two structures, objects and arrays, holding six value types, and once you see those two structures everything else is nesting. An object groups named values; an array lists ordered values; and values can themselves be objects or arrays, which is how complex data is built up.

An object is a collection of key-value pairs inside curly braces, used to represent a single entity with named properties. Each key is a name in quotes, each value is the data for that key. A payment is naturally an object: it has a debtor, a creditor, an amount, a currency, each a named property. An array is an ordered list of values inside square brackets, used to represent multiple items. A list of payments is naturally an array. The values come in six types: strings (text in double quotes), numbers (no quotes, integer or decimal), booleans (true or false), null (an explicit empty value), objects, and arrays. That last point is the key to everything: because a value can be an object or an array, structures nest, and nesting is how JSON represents anything from a simple record to a deeply structured payment message.

{
  "uetr": "abc-123",          // string
  "amount": 100.50,            // number
  "urgent": true,              // boolean
  "reasonCode": null,          // null (no rejection)
  "creditor": {                // nested object
    "name": "Jane Doe",
    "account": "DE89..."
  },
  "tags": ["sepa", "instant"]  // array of strings
}

That single example contains every concept: an object at the top, the six value types, a nested object for the creditor, and an array for the tags. Once you can read that, you can read any JSON, because all JSON is this pattern repeated and nested. The simplicity is the point, two structures and six types compose into everything, which is why fluency comes fast and pays off everywhere.

How do you read a nested JSON payload?

Read a nested payload by drilling in: start at the top object, follow the keys to the data you need, and when a value is itself an object or array, go into it and repeat. Nesting is the one thing that looks intimidating at first and becomes routine once you treat it as drilling down a path.

The mental model is a path. To find the creditor’s account in the example above, you go: top object, then the creditor key, then the account key within it, a path of creditor.account leading to the value. For data inside an array, you add position: the first tag is tags[0]. Real payment messages, especially ISO 20022 ones rendered as JSON, nest several levels deep, a payment contains a creditor which contains an account which contains an identifier, and you navigate them the same way every time, one key at a time, drilling toward the value you want. The depth can look daunting in a large payload, but the operation is always the same simple step, so depth is just more steps, not more difficulty.

This drilling skill is exactly what you need to read an API response in a test or an event on a topic. When you assert that a test response has the right status, you are navigating to a key and checking its value; when you validate an event, you are drilling into its payload to confirm the fields. The path notation also matches how you reference fields in scripts and assertions, so reading JSON by path and scripting checks against it are the same mental motion. Becoming comfortable navigating nested structures is the single most useful JSON skill, because real data is always nested, and it connects directly to the data dictionary work of knowing what each field at each path means.

Why do JSON types matter for an analyst?

JSON types matter because they affect validation and meaning, and an analyst who ignores types will write imprecise requirements and miss real defects. The number 100 is not the string “100”, and null is not the same as an absent key, and these distinctions have consequences.

Consider the number versus string distinction. An amount sent as the number 100.50 is data a system can do arithmetic on; the same amount sent as the string "100.50" is text that must be parsed first and may fail validation. Specifying that a field is a number versus a string is a real requirement, and a system that expects one and receives the other produces a defect. In API requirements and the data dictionary, the type of each field is part of its definition for exactly this reason. Consider null versus absent: a reasonCode that is explicitly null says “there is no reason code, deliberately,” while a reasonCode key that is simply missing says “this field was not provided at all.” Those can mean different things, a deliberate empty value versus an omission, and systems often treat them differently, so the distinction can be a requirement and a test case.

These type distinctions are exactly where subtle integration defects live. A field that should be a number arriving as a string, a null where the consumer expected a value, a boolean sent as the string “true”, each is a real bug that you only catch if you are reading the types, not just the values. This is why an analyst’s JSON fluency must include types, not just structure: the structure tells you the shape, the types tell you the precise meaning, and the precise meaning is what makes requirements correct and tests sharp. It is the same precision that distinguishes a functional spec that builds cleanly from one that generates defects, applied at the level of the individual value.

Where does JSON fluency fit in the toolkit?

JSON fluency is the connective skill that makes the rest of the technical toolkit usable, because JSON is the format the other skills operate on. Reading contracts, testing APIs, validating events, and reading config all involve reading JSON, so fluency in it amplifies every one of them.

The connections are everywhere. An API contract defines its request and response schemas as JSON structures, so reading the contract is reading JSON. API testing means sending and asserting JSON payloads. Event validation means reading the JSON of the event. Scripting checks means parsing JSON responses, which map directly onto the objects and arrays you now recognize. Even configuration is often JSON, so understanding how a system is set up is reading JSON. In each case, JSON is the medium, and being unable to read it fluently is a bottleneck on every one of these skills, while fluency removes the friction from all of them at once.

This is why JSON belongs early in the developer analyst learning path, alongside SQL and status codes: it is a small skill that unlocks larger ones. And like those, it is learned by use, read the real payloads from systems you work with, the actual API responses and events, rather than abstract examples, and the structures quickly become second nature. Within a short time, a JSON payload stops being a wall of brackets and becomes a readable description of exactly what data is moving, which is the self-sufficiency that defines the technical business analyst. The structured path through JSON and its sibling skills is The Technical Skills Guide for BAs.

The takeaway

JSON is the format of API payloads, events, and config across modern systems, and it is built from just two structures, objects and arrays, holding six value types. Read it by drilling down the path to the data you need, treating nesting as repeated simple steps, and pay attention to types, because a number is not a string and null is not absent, distinctions where real defects hide. Fluency is the connective skill that makes reading contracts, testing APIs, validating events, and reading config all flow.

It is a small investment learned in an afternoon by reading real payloads, and it removes friction from every technical task an analyst does. Start with The Technical Skills Guide for BAs and API Documentation from Scratch, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Technical Skills, JSON, API, Data, Career Growth