200 OK With Broken Data: Why API Status Codes Are Not Enough to Monitor

Your API endpoint returns 200 OK. Your monitoring dashboard is green. Your users are looking at a blank product catalogue, an empty dashboard, or a broken checkout — because the response body contained {"products": []} instead of the 847 products it should have returned.

The status code was correct. The data was wrong. Your monitoring had no opinion on this.

This is not an edge case. Every serious production system has experienced a variant of this failure. The assumption that "200 OK = working API" is one of the most expensive monitoring gaps in production engineering.

What 200 OK Actually Proves

Precisely and only this: the server received the HTTP request and returned a successful response code. Nothing about what was in the response body. Nothing about whether the data was correct, complete, or structurally sound.

A server returning 200 OK with:

• {"users": []} — empty user list
• {"price": null} — null price on a checkout page
• {"data": "undefined"} — a JavaScript serialisation bug
• {"products": [...stale data from 6 hours ago...]} — cached incorrect data
• {} — completely empty object

...is indistinguishable from one returning correct data, as far as HTTP status code monitoring is concerned. Both are "up."

Why Tests Don't Catch This in Production

Your unit tests mock the database. Your integration tests run against a controlled test dataset. Neither tests whether the production database query returned the expected number of rows. Neither catches a caching layer that started serving stale data three hours ago. Neither detects a feature flag that silently removed a required field from the response.

Production API response validation monitoring fills exactly this gap — it checks what your API actually returns, against what it should return, in production, continuously.

5 API Failure Modes That Return 200 OK

These are the five failure patterns that cause the most user-visible damage while remaining completely invisible to status code monitoring.

1. Empty arrays from database query failures. Your product listing endpoint queries the database, encounters a slow query timeout, catches the exception, and returns {"products": []} with a 200 status — an "empty success" that looks correct to the server but represents a failure from the user's perspective. Users see a blank product page. Your monitoring sees 200 OK.

2. Stale cache serving outdated data. Your CDN or application cache aggressively caches API responses. A content update, a price change, or a product removal is deployed to the database, but the cache TTL hasn't expired. Requests return 200 OK with the old data. This can persist for hours. Users see prices, products, or content from hours ago. Status code monitoring sees a healthy 200.

3. Null or undefined fields from schema migrations. A backend schema migration adds a new required field or renames an existing one. Old response data in the cache, or a migration that runs partially, causes some API responses to return null for a field the frontend expects to be present. The frontend breaks, but the API returns 200 OK.

4. Feature flags silently removing data. A feature flag change disables a feature mid-deployment, removing the data that feature provided from API responses. The response structure is still valid JSON, the status is still 200, but critical fields are absent. Depending on how the frontend handles missing data, this causes anything from blank sections to JavaScript errors.

5. Third-party API aggregation failures. Your API aggregates data from a third-party service. When the third-party service fails, your API catches the error and returns a partial response with 200 OK — perhaps with a "thirdPartyData": null field. Depending on how the frontend handles this, users see incomplete information or broken functionality.

API Monitoring Levels

The right monitoring stack covers all three levels:

Status code monitoring is necessary but not sufficient. Response body validation is the missing layer for most teams.

How to Validate API Response Bodies in Production

There are three practical approaches to API response body validation, each with different coverage and complexity.

Approach 1: Non-Empty Body Assertion

The minimum viable check: verify the response body is not empty and not an empty array/object for endpoints that should return data.

// Basic response body validation
async function checkApiEndpoint(url, expectedMinLength = 1) {
  const response = await fetch(url, {
    headers: { 'Authorization': `Bearer ${process.env.MONITOR_API_TOKEN}` }
  });

  if (response.status !== 200) {
    throw new Error(`Expected 200, got ${response.status}`);
  }

  const body = await response.json();

  // Check array responses are not empty
  if (Array.isArray(body)) {
    if (body.length < expectedMinLength) {
      throw new Error(`Expected at least ${expectedMinLength} items, got ${body.length}`);
    }
  }

  // Check object responses have required fields
  if (typeof body === 'object' && body !== null) {
    const requiredFields = ['id', 'name', 'status'];
    for (const field of requiredFields) {
      if (body[field] === undefined || body[field] === null) {
        throw new Error(`Required field '${field}' is missing or null`);
      }
    }
  }

  return { status: 'pass', itemCount: Array.isArray(body) ? body.length : 1 };
}

Approach 2: JSON Schema Validation

Define the expected schema for your API response and validate every monitored response against it:

const Ajv = require('ajv');
const ajv = new Ajv();

// Define your expected API response schema
const productListSchema = {
  type: 'object',
  required: ['products', 'total', 'page'],
  properties: {
    products: {
      type: 'array',
      minItems: 1,              // Fail if products array is empty
      items: {
        type: 'object',
        required: ['id', 'name', 'price', 'available'],
        properties: {
          id: { type: 'string' },
          name: { type: 'string', minLength: 1 },
          price: { type: 'number', minimum: 0 },
          available: { type: 'boolean' }
        }
      }
    },
    total: { type: 'number', minimum: 0 },
    page: { type: 'number', minimum: 1 }
  }
};

async function validateApiResponse(url) {
  const response = await fetch(url);
  const body = await response.json();

  const validate = ajv.compile(productListSchema);
  const valid = validate(body);

  if (!valid) {
    throw new Error(`Schema validation failed: ${ajv.errorsText(validate.errors)}`);
  }

  return { status: 'pass', productsReturned: body.products.length };
}

Approach 3: Snapshot-Based Drift Detection

For APIs where the exact response is predictable (configuration endpoints, lookup data, critical constants), compare the current response against a known-good snapshot:

async function detectApiDrift(url, snapshotPath) {
  const response = await fetch(url);
  const currentBody = await response.json();
  const snapshot = JSON.parse(fs.readFileSync(snapshotPath, 'utf8'));

  // Compare critical fields
  const driftReport = compareStructure(snapshot, currentBody);

  if (driftReport.fieldsRemoved.length > 0) {
    throw new Error(`API DRIFT: Fields removed: ${driftReport.fieldsRemoved.join(', ')}`);
  }

  if (driftReport.typeChanges.length > 0) {
    throw new Error(`API DRIFT: Type changes: ${driftReport.typeChanges.join(', ')}`);
  }

  return { status: 'pass', drift: driftReport };
}

Setting Up API Response Monitoring in PingSLA

PingSLA's API Deep-Scan tool goes beyond status code checking to validate API responses at multiple levels:

• Response body non-empty check
• Required field presence validation
• Response schema structure validation
• Response time measurement and trending
• Multi-region validation (check your API from BLR, Mumbai, Singapore simultaneously)

For each API endpoint you add to PingSLA, you configure:

1. The endpoint URL and authentication headers
2. Expected response schema or required fields
3. Minimum response body requirements (e.g., array must have at least 1 item)
4. Alert thresholds (schema drift, empty response, slow response)

When the response fails your validation rules — even with a 200 OK status — PingSLA fires an alert through your configured channels (WhatsApp, Slack, email, PagerDuty).

What is API response validation monitoring?

API response validation monitoring checks not just that an API endpoint returns a 200 OK status code, but that the response body matches an expected structure, contains required fields, and meets minimum data requirements. It catches silent failures where the API responds successfully but returns empty, malformed, or incorrect data.

Why isn't checking the HTTP status code enough for API monitoring?

HTTP status codes communicate whether the server handled the request, not whether the response data is correct or complete. A 200 OK response can contain an empty array, null required fields, stale cached data, or a malformed JSON structure — all of which cause user-visible failures while the status code monitoring shows green.

What should I check in an API response beyond status code?

At minimum: that the response body is not empty, that required fields are present and non-null, and that array responses contain at least the expected minimum number of items. For critical APIs, add JSON Schema validation to catch structural changes (field renames, type changes, nested object changes) that break frontends without changing status codes.

How often should API response validation run in production?

Every 1–5 minutes for APIs that power user-facing features. The check frequency should match the impact of the failure — checkout APIs and authentication endpoints warrant every 1 minute, while less critical endpoints can run every 5 minutes. Response validation checks take slightly longer than status code checks (parsing the body adds ~50–200ms), so factor this into your check budget.

What is API contract monitoring?

API contract monitoring is the practice of defining and continuously verifying the "contract" between an API and its consumers — the agreed structure, field types, required fields, and semantics of the API response. It's a superset of response body validation that also covers semantic correctness (e.g., price should never be negative) and compatibility between producer and consumer schemas.

Your APIs are probably returning 200 OK right now. The question is whether they're returning the right data. PingSLA's API Deep-Scan validates your API response body, schema, and latency in a single check — free, no account required.

For continuous API response monitoring with schema validation, multi-region checks, and WhatsApp alerts when your data goes wrong, see PingSLA plans.

Related reading: Monitor API Endpoints · Uptime Monitoring Is Not Enough · Login Flow Monitoring