Third-party API Monitoring#

Your app calls out to a payment processor, an auth provider, a shipping rate service, a mail sender. When one of them breaks, your app breaks with it, and you usually hear about it from a customer. Assert watches those endpoints on the same schedule as your own.

The Problem#

Their outage becomes yours:

• Payments: Stripe has an incident and your checkout stops taking money
• Auth: Auth0 goes down and nobody can log in
• Shipping: the FedEx API times out and you can't quote a rate
• Stale data: the weather API stops updating and today's forecast is yesterday's

You can't fix any of it. You can know first, and say so before anyone asks.

How Assert Helps#

Monitor Vendor Health Endpoints#

Most services have status endpoints:

Monitor: Stripe Health
URL: https://status.stripe.com/api/status
Assertions:
  ✓ $.status == "operational"
  ✓ Response time < 2000ms

Monitor Your Integration Points#

Check the specific endpoints you use:

Monitor: Stripe API - Payment Methods
URL: POST https://api.stripe.com/v1/payment_methods
Headers: Authorization: Bearer sk_test_xxx
Body: type=card
Assertions:
  ✓ Status code == 200 or 400
  ✓ $.error does not exist
  ✓ Response time < 3000ms

Monitor from User Regions#

Third-party performance varies by location:

Monitors from:
  ✓ US East (primary users)
  ✓ Europe (GDPR region)
  ✓ Asia Pacific (global users)

Assert runs every check from six regions and compares them before it alerts, so a vendor that is only slow in Frankfurt shows up as exactly that.

Critical Third-Party APIs to Monitor#

Authentication & Identity#

Payments#

Communication#

Cloud Services#

Data & Analytics#

Real-World Example#

The Scenario#

A SaaS app authenticates through Auth0. Auth0's latency spikes, logins crawl, users complain, and the ops team reads its own traces for an hour before anyone thinks to blame the vendor.

The Assert Solution#

Monitor 1: Auth0 Token Endpoint

URL: POST https://your-tenant.auth0.com/oauth/token
Headers:
  Content-Type: application/x-www-form-urlencoded
Body:
  grant_type: client_credentials
  client_id: xxx
  client_secret: xxx
  audience: https://api.example.com
Assertions:
  ✓ Status code == 200
  ✓ $.access_token exists
  ✓ Response time < 2000ms
Interval: 1 minute
Regions: US East, Europe

Monitor 2: Auth0 Status Page

URL: GET https://status.auth0.com/api/v2/status.json
Assertions:
  ✓ $.status.indicator == "none"
Interval: 5 minutes

The Outcome#

The token monitor caught the latency five minutes before the first complaint. The team switched to cached tokens, put a banner on the login page, and the support queue stayed empty.

Monitoring Strategies#

Direct API Monitoring#

Monitor the actual endpoints you use:

Pros:
  ✓ Tests your actual integration
  ✓ Uses your credentials
  ✓ Catches integration issues

Cons:
  ✗ May incur API costs
  ✗ Rate limits apply
  ✗ Credentials in monitoring

Status Page Monitoring#

Monitor vendor status endpoints:

Pros:
  ✓ No API costs
  ✓ No rate limits
  ✓ No credentials needed

Cons:
  ✗ May lag behind actual issues
  ✗ Doesn't test your integration
  ✗ Not all vendors have them

Do Both#

A direct check tells you your integration still works. A status page tells you it isn't only you. Run both against anything that would stop your product.

Critical vendors: Direct API + Status page
Other vendors: Status page only

Assertions for Third-Party APIs#

Assert reads the status, the latency, any response header and any JSON path in the body, which covers most of what a vendor will tell you about itself.

Availability#

✓ Status code == 200
✓ Response time < 5000ms
✓ $.status != "error"

Data Quality#

✓ $.data exists
✓ $.data is array
✓ $.data.length > 0

Rate Limits#

Monitor rate limit headers:

✓ X-RateLimit-Remaining > 100
✓ X-RateLimit-Reset within 1 hour

Version Compatibility#

✓ $.api_version == "2024-01"
✓ $.deprecated != true

Best Practices#

Use Test/Sandbox Credentials#

When possible, use sandbox environments:

Production: api.stripe.com (with live key)
Sandbox: api.stripe.com (with test key) ← Monitor this

Set Realistic Thresholds#

Third-party APIs can be slower than yours:

Create Runbooks#

Document what to do when each vendor fails:

## Auth0 Down Runbook
1. Check status.auth0.com
2. Enable cached token validation
3. Notify users via banner
4. Open Auth0 support ticket

Monitor Dependencies of Dependencies#

Your vendor relies on others too:

Your App → Auth0 → AWS
Your App → Stripe → Payment Networks

If Auth0's outage is really an AWS outage, the status page you're watching is the wrong one.

Alert Configuration#

Critical (Immediate)#

Service: Payment provider
Condition: 5xx errors or timeout
Action: Page on-call + Slack
Reason: Revenue impacting

High (Fast Response)#

Service: Authentication
Condition: Response time > 3000ms
Action: Slack #engineering
Reason: User experience impact

Medium (Business Hours)#

Service: Analytics provider
Condition: Status degraded
Action: Email
Reason: Non-critical, review later

Getting Started#

1. List every external API your app calls. Grep the codebase if the list isn't written down.
2. Sort by blast radius. Auth and payments first.
3. Find each vendor's status endpoint in their docs.
4. Build the monitors: direct check, status page, or both.
5. Route the alerts by how much the outage costs you.

Related Use Cases#

• Payment API Monitoring: payment providers in detail
• Webhook Reliability: the events those vendors push back to you