API Endpoint Monitoring

A 200 OK does not
mean everything is fine

Your API returned 200. But the response body was empty. The data was stale. A required field was missing. Status codes lie. Response validation catches the truth.

GEThttps://api.example.com/v2/orders?status=active

Request Headers

Authorization: Bearer sk_live_*****mX4q

Accept: application/json

X-Request-ID: mon_8f2a1b

Waiting for next check...

Response validation

Six ways to validate every response

A successful HTTP status code is the bare minimum. Real API monitoring means validating the entire response: the body, the headers, the timing, and the structure. Pulse Stack™ runs your assertions against every check and fails the moment any rule breaks.

This is what separates API monitoring from basic uptime checks. A website monitor confirms the server responded. An API monitor confirms the response was correct, complete, and fast enough. The difference matters when your mobile app, your checkout flow, or your partner integration depends on that data.

Click through the assertion types to see how each one works. Every assertion runs on every check from every monitoring location, giving you comprehensive coverage with zero blind spots.

assertresponse.statusequals200
result:200PASS

Status code equals 200

Endpoint latency (last 24h)

/v2/ordersOK
P50: 89msP95: 210msP99: 480ms
/v2/users/authOK
P50: 42msP95: 95msP99: 145ms
/v2/searchSLOW
P50: 320msP95: 890msP99: 1450ms
/v2/paymentsOK
P50: 155msP95: 340msP99: 520ms
/v1/webhooksOK
P50: 65msP95: 130msP99: 195ms
P50 (median)
P95
P99

Performance tracking

Averages hide your worst failures

An API with 100ms average response time sounds fast. But if 1% of requests take 2 seconds, that is thousands of frustrated users per day. Percentile tracking reveals what averages conceal.

P50 tells you the typical experience. P95 tells you what the unlucky 5% of your users see. P99 tells you your worst case. Set alert thresholds on any percentile. A P95 that creeps from 200ms to 800ms over a week signals a problem developing, even if P50 stays flat.

Pulse Stack™ measures latency from 10+ global locations simultaneously. Your API might be fast from US East but slow from Europe. Regional performance gaps surface immediately in the percentile data, so you can optimise CDN configuration or add edge caching where it matters.

Pair latency tracking with response time monitoring for complete performance visibility across your entire stack, from network layer to application layer.

One failed API breaks the entire chain

Modern applications call dozens of APIs. When a payment provider returns 503, your checkout fails. When the email service times out, order confirmations vanish. Monitor every link in the chain.

Your App

healthy

Auth API

healthy

Payment API

503 error

Email Service

timeout

Analytics

healthy

Third-party APIs

Stripe, Twilio, SendGrid, OpenAI, and every other external dependency. You cannot control their uptime, but you can know within 30 seconds when they degrade.

Integration monitoring

Internal microservices

Your auth service, user service, search engine, and recommendation API. Each one is a potential single point of failure. Monitor them all from outside your network for a true user perspective.

Port monitoring

Webhook endpoints

Payment callbacks, CI/CD triggers, and event notifications. If your webhook receiver goes down, you lose events permanently. Heartbeat monitoring catches receiver failures fast.

Heartbeat monitoring

Monitor your first endpoint in 30 seconds

Enter a URL, set your assertions, pick your alert channels. Done.

Start free

Monitor every HTTP method

Different methods have different failure modes. Pulse Stack™ supports all of them with method-specific validation strategies.

GET

The most common monitor type. Fetch data endpoints and validate response structure, field presence, and data freshness. Check that list endpoints return expected item counts and that detail endpoints include all required fields.

Status 200JSON body validResponse < 500ms
POST

Test creation endpoints with specific request bodies. Verify that your order creation, user registration, and form submission APIs accept valid payloads and return proper confirmation responses with generated IDs.

Status 201Body has "id"Location header set
PUT / PATCH

Validate update endpoints by sending partial or complete payloads. Confirm that the API returns the updated resource and that modified fields reflect the changes. Catches schema drift that breaks client updates.

Status 200Updated fields matchETag changed
DELETE

Verify that deletion endpoints respond correctly. Some return 204 with no body, others return 200 with the deleted resource. Monitor that your cleanup and cancellation APIs still behave as your clients expect.

Status 204Empty bodyResponse < 200ms

Beyond uptime

Why status codes are not enough

The biggest misconception in API monitoring is that a 200 response means everything is fine. In practice, APIs fail in subtle ways that status codes never reveal. A search endpoint that returns zero results when the database index is corrupted. A pricing API that returns cached data from two hours ago because the refresh job failed. An authentication endpoint that accepts any token because the validation middleware crashed.

These are not hypothetical scenarios. They happen in production systems every day. The API returns 200 because the web framework handled the request. But the data is wrong, incomplete, or dangerously stale. Your users see broken prices, missing search results, or security vulnerabilities, and your basic uptime monitor shows 100% availability.

Response validation closes this gap. By asserting on the actual content of every response, you catch data-level failures at the monitoring layer instead of relying on user reports or incident escalations. Combine API monitoring with content monitoring for your web pages to verify data correctness across both your API layer and your presentation layer.

For teams running microservice architectures, monitoring individual endpoints is not optional. Each service is a dependency for other services. Use API monitoring alongside port monitoring to confirm services are both accepting connections and returning valid data.

Supported authentication

Bearer Token

JWT, OAuth access tokens, API keys in Authorization header

API Key Header

X-API-Key, X-Auth-Token, or any custom header name

Basic Auth

Username and password encoded in the Authorization header

Query Parameter

API key passed as a URL query parameter

Custom Headers

Any combination of request headers your API requires

Request Body Auth

Credentials included in POST/PUT request payloads

Simple pricing. Start free.

50 monitors free forever. Upgrade when you need faster checks or more capacity.

Free

£0forever

  • 50 monitors
  • 3-min checks
  • Email alerts
  • 5 status pages
Start free

Most popular

Pro

£29/month

  • 200 monitors
  • 30-sec checks
  • All 16+ alert channels
  • 90-day data retention
Get started

Enterprise

£89/month

  • 500+ monitors
  • 30-sec checks
  • SSO & audit logs
  • Dedicated support
Contact us

All plans include multi-location checks, incident management, and public status pages. Full plan comparison →

Frequently asked questions

Everything you need to know about API endpoint monitoring.

What is your API actually returning?

Validate every response from every endpoint. Free for 50 monitors, no credit card required.

Start API monitoring free