4 Steps: Extract Nested Arrays JSONPath Online Tester

Quick Win: Use $..items[*] Before You Write Any Code

Before you touch a single line of Python or JavaScript to parse a gnarly API response, paste the payload into a JSONPath online tester and run $..items[*]. That recursive descent operator (..) grabs every items array no matter how deeply it's buried. I use this trick almost every morning when a vendor pushes a schema change and my pipeline quietly breaks. It takes about 8 seconds to confirm whether the data is still there — just buried one level deeper than yesterday.

Below, I'll walk you through the exact six-step checklist I follow as an integrations engineer when I need to extract nested arrays from third-party API responses. Every step happens inside the browser, using a JSONPath online tester as a scratchpad. No IDE required.

Step 1: Paste the API Response and Visually Locate the Nested Array

Start by dumping your raw JSON into the left panel of the tester. Most JSONPath online testers auto-format and tree-fold the structure, which is honestly half the value. You're not just querying — you're orienting yourself.

What you're looking for is the repeating pattern. APIs from platforms like Shopify, HubSpot, or Stripe love to wrap arrays inside pagination objects, which are themselves nested inside a data or results envelope. A typical response might look like:

{"data":{"orders":[{"id":1,"items":[{"sku":"A1","qty":2},{"sku":"B2","qty":1}]},{"id":2,"items":[{"sku":"C3","qty":5}]}]}}

See how items sits inside each order object, which itself sits inside data.orders? That's a nested array. Your job is to pull every items entry across all orders into a flat list. Keep that goal in your head — it'll shape every expression you write from here.

Step 2: Decide Between Recursive Descent and Explicit Dot Notation

This is where most people trip. You have two main paths:

Path A — Recursive Descent: $..items[*]

Use this when you're not 100% sure how deep the arrays sit, or when the API vendor has inconsistent nesting (yes, that happens more than you'd think). The .. tells the JSONPath engine to search at every level. The [*] says "give me all elements inside each match."

Path B — Explicit Path: $.data.orders[*].items[*]

Use this when you know the exact structure and you want to avoid accidentally grabbing some unrelated items field buried in a metadata block somewhere. Explicit paths are safer and faster — but they break the moment the vendor adds a wrapper layer.

My rule of thumb: start with Path A in the tester to confirm the data exists, then switch to Path B for production code. You get speed during exploration and precision during execution.

Step 3: Build Your Expression Incrementally — Don't Go All-In

Here's a habit that's saved me countless hours: build your JSONPath expression one segment at a time and hit "Evaluate" after each addition. Treat the tester like a REPL, not a one-shot query box.

Let's say you're working with that Shopify-style response from Step 1. Your incremental build looks like this:

• $.data — confirms the top-level envelope exists.
• $.data.orders — confirms the orders array is where you expect.
• $.data.orders[*] — returns every order object. Check the count. If the API returned 47 orders, you should see 47 objects.
• $.data.orders[*].items — returns a list of arrays (one per order). Not flat yet, but you're close.
• $.data.orders[*].items[*] — flattens everything into a single array of item objects. This is your extraction target.

Each step gives you a checkpoint. If step three returns zero results, you know exactly where the path broke — no guessing.

Step 4: Add Filters When You Only Need a Subset of the Nested Array

Sometimes you don't want every item. You want items where qty is greater than 1, or where sku starts with "A". JSONPath filter expressions handle this, and the online tester is the perfect place to prototype them.

The syntax looks like this:

$.data.orders[*].items[?(@.qty > 1)]

The ? introduces a filter, and @ refers to the current item being evaluated. So @.qty > 1 means "keep only items where the qty field exceeds 1."

Run that in the tester and you should get back only the matching objects. In our example payload, that would return {"sku":"A1","qty":2} and {"sku":"C3","qty":5} — two items out of three total. That's a 66% reduction in payload size before the data ever hits your downstream code.

Pro Tip: Test Multiple Filters Together

You can chain conditions with && and ||:

$.data.orders[*].items[?(@.qty > 1 && @.sku ~= "A.*")]

That regex match (~=) filters for SKUs starting with "A". Pop it in the tester, check the result count, and adjust. Doing this in code would require a redeploy — doing it in the tester takes one keystroke.

Step 5: Stress-Test Against Edge Cases Before You Ship

This step separates decent engineers from reliable ones. Before you copy that polished JSONPath expression into your pipeline, throw edge cases at it in the tester:

• Empty arrays: What if an order has zero items? Does your expression return an empty array, or does it error out?
• Missing keys: What if one order object doesn't have an items field at all? Recursive descent handles this gracefully; explicit paths may throw.
• Null values: What if items is null instead of an array? Some APIs do this. Your filter expression should skip nulls cleanly.
• Deeply nested variants: Paste a response with 5 levels of nesting instead of 2. Does $..items[*] still return the right set, or does it grab something unexpected from a metadata block?

I keep a folder of five or six "weird payload" JSON files for this exact purpose. When a vendor API changes, I run my expression against all of them in the tester before touching production code. It's boring, but it's the kind of boring that prevents 2 a.m. incident alerts.

Step 6: Export the Result and Document the Expression

Most JSONPath online testers let you copy the extracted result as formatted JSON. Grab it. Then do two things:

First, paste the result into a quick validation script or spreadsheet to confirm the row count and field integrity match what you expected. If you extracted 312 items from a 47-order response, does that average (~6.6 items per order) make sense for this API? Sanity checks like this catch silent data loss.

Second, document the final expression in your internal wiki or code comments. Include the API version, the date you validated it, and a sample input/output pair. When someone else on your team inherits this pipeline three months from now, they'll thank you.

Here's the format I use:

JSONPath: $.data.orders[*].items[?(@.qty > 1)]
Source: Vendor Orders API v3.2
Validated: 2025-01-15
Input: 47 orders → Output: 312 items (filtered to 89)

Wrapping Up the Checklist

That's the full workflow: paste, orient, build incrementally, filter, stress-test, and document. Six steps, all inside a browser-based JSONPath online tester. The beauty of this approach is that you catch structural issues and logic errors before they reach your codebase. Every minute spent in the tester saves roughly five minutes of debugging later — I've tracked it across roughly 40 API integration projects over the past two years.

Keep this checklist bookmarked. The next time a vendor pushes a schema change at 4 p.m. on a Friday, you'll have a calm, repeatable process instead of a frantic code-and-pray session.