JSON API Monitoring With Assertions: Validate Response Data, Not Just Status Codes

Your API returns HTTP 200. Everything is fine, right? Not necessarily. The response body could contain an empty array instead of data. A critical field could be null. The pagination could be broken. An upstream dependency could be failing silently while your API dutifully returns a 200 status with an error message buried in the JSON body. Status code monitoring misses all of this. JSON API monitoring with assertions catches it — and catching it is the difference between a five-minute fix and a four-hour outage that your customers discover before you do.

What Are JSON Assertions?

Assertions are rules that validate the actual content of your API response. Instead of just checking "did I get a 200?", assertions let you verify the structure and values of the JSON payload. They use JSONPath expressions — a query syntax for navigating JSON structures, similar to how XPath works for XML.

Monitorion supports several assertion types:

• Field existence — verify that $.data exists and is not null
• Equality — confirm that $.status equals "active"
• Array length — assert that $.items has at least 1 element
• Numeric comparison — verify that $.price is greater than 0
• String containment — check that $.message contains "success"

You can combine multiple assertions on a single monitor. All must pass for the check to be marked as successful. If any assertion fails, Monitorion records which assertion failed and what the actual value was, so you can diagnose the issue without manually calling the API.

Setting Up JSON API Monitoring

In your Monitorion dashboard, go to Monitors → New Monitor → JSON API. The configuration is straightforward:

• URL — your API endpoint, including any query parameters. For example: https://api.example.com/v2/products?limit=10
• Method — GET, POST, PUT, PATCH, or DELETE. Choose the method that matches how your API is called in production.
• Headers — add Authorization headers (Bearer tokens, API keys), Content-Type, Accept, or any custom headers your API requires.
• Request Body — for POST, PUT, and PATCH requests, include the JSON body. This lets you monitor endpoints that require input data, like search APIs or mutation endpoints.
• Assertions — one or more JSONPath assertions to validate the response. Add as many as you need to verify the response is correct.

Real-World Assertion Examples

Here are practical assertion configurations for common API monitoring scenarios:

Health Check Endpoint

Most APIs expose a /health or /status endpoint. A basic HTTP check only confirms the endpoint responds. Assertions verify that every dependency is actually healthy:

URL: https://api.example.com/health
Assertion: $.status equals "ok"
Assertion: $.database equals "connected"
Assertion: $.cache equals "connected"

This catches the scenario where your API process is running but the database connection pool is exhausted or the Redis cache is unreachable. The health endpoint returns 200 because the HTTP server is alive — but the assertions reveal that critical dependencies are failing.

Product Listing and E-Commerce APIs

For e-commerce APIs, an empty product list is functionally equivalent to an outage — even though the API returns 200. A payment gateway returning slow responses means abandoned carts. Assertions catch both:

Product API:
  URL: https://api.example.com/products?category=featured&limit=10
  Assertion: $.data exists
  Assertion: $.data.length > 0
  Assertion: $.meta.total > 0

Payment status:
  URL: https://api.example.com/payment/status
  Assertion: $.gateway equals "online"
  Assertion: $.processingTime < 5000

The array length assertion catches broken database queries and permission regressions. The numeric comparison on processingTime catches performance degradation before checkout abandonment rates spike.

Authentication and Third-Party Dependencies

Auth services are notorious for returning 200 with error bodies. Third-party APIs can change their response format without notice. For an auth endpoint, assert $.valid equals true and $.user exists to verify the token flow works end to end. For a third-party data feed, assert that key fields like $.rates exist and contain valid numeric values. Both catch failures that status code checks completely miss.

Common Failure Patterns That Assertions Catch

These are real scenarios that HTTP status code monitoring completely misses. A database migration breaks a query filter — the API returns 200 with an empty products array and your store shows zero items for hours. An assertion checking $.products.length > 0 catches it within one check interval. Your CDN caches a 200 response containing {"error": "rate limit exceeded"} — an assertion verifying $.error does not exist catches it immediately.

Upstream dependencies fail silently too. Your API calls a third-party service for enrichment data. When that service is down, your API returns the base record with null fields. The response is 200, the structure looks right, but critical data is missing. An existence assertion on the enrichment fields catches it. A teammate renames $.user.email to $.user.email_address in a refactor, and the frontend shows "undefined." An existence assertion catches the breaking change — especially powerful if you monitor your staging API before deployment.

Monitoring Strategy for APIs

Focus assertions on the endpoints that directly affect user experience and revenue — authentication, product listing, checkout, and search. You do not need to monitor your admin settings API with the same rigor. Always use realistic requests: if your API requires authentication, configure the monitor with a real API key or token, because an unauthenticated 401 tells you nothing useful.

Combine JSON API monitors with standard HTTP monitors. The HTTP monitor catches complete outages with minimal overhead, while the JSON monitor catches data-level failures that HTTP monitors miss. Run the same assertions against your staging environment too — catch breaking changes during QA instead of after deployment. For critical payment and auth APIs, check every 1 minute; for content APIs and third-party dependencies, every 5 minutes is usually sufficient.

JSON API monitoring with assertions is available on Monitorion Pro plans and above. It is one of the 25 monitor types included in the platform — no add-ons, no extra charges. Because HTTP 200 does not mean your API is working correctly, and your monitoring should be smart enough to know the difference.

Ready to get started? Sign up free and upgrade to Pro to start validating your API responses with assertions.