E-commerce API Monitoring
Your storefront reads from APIs for the catalog, stock levels, the cart and checkout. When one of them answers with the wrong data, a customer sees an empty grid or last month's price, and the sale goes somewhere else.
The Problem
The pricing API serves a stale cache and the product page shows last month's price. Inventory sync stalls and a sold-out SKU still reads as available. Payment processing drops and checkout fails on the last step. The catalog API's response time climbs and every product page crawls.
An uptime monitor sees 200 on all four.
How Assert Helps
Assert reads the body of the response. One check covers the status, the latency, any response header and any JSON path inside it.
Monitor Product APIs
Ensure your product catalog returns correct data:
Monitor: GET /api/products/featured
Assertions:
✓ $.products.length > 0
✓ $.products[*].price > 0
✓ $.products[*].in_stock exists
✓ Response time < 500ms
That catches an empty listing, a missing price, a null stock count, and a catalog that has quietly slowed to a crawl.
Monitor Inventory APIs
Validate inventory sync is working:
Monitor: GET /api/inventory/SKU-12345
Assertions:
✓ $.quantity >= 0
✓ $.last_updated within 1 hour
✓ $.warehouse_id exists
Negative counts, sync data that hasn't moved in an hour, and missing warehouse mappings all fail here.
Monitor Checkout Flow
Ensure checkout APIs are operational:
Monitor: POST /api/checkout/validate
Assertions:
✓ $.valid == true
✓ $.payment_methods.length > 0
✓ $.shipping_options.length > 0
A cart that won't validate, a payment method that has disappeared or a shipping calculator that returns nothing will trip one of these three.
Real-World Example
The Scenario
An online retailer's product API occasionally returns empty arrays during high traffic. The API returns 200 OK, so uptime monitors don't alert. Customers see "No products found" on the homepage.
The Assert Solution
Monitor: Production Product API
URL: https://api.store.com/products/featured
Method: GET
Interval: 1 minute
Regions: US East, US West, Europe
Assertions:
- $.products must be array
- $.products.length must be > 0
- $.products[0].id must exist
- $.products[0].price must be > 0
- Response time must be < 1000ms
Alerts:
- Slack: #ecommerce-alerts
- PagerDuty: E-commerce On-Call
The Outcome
The monitor failed 60 seconds after the first empty response, rather than hours later when the support queue filled up. Assert paged the on-call engineer once, with the failing response attached. The cause was database connection pool exhaustion. The fix went out and the monitor auto-resolved on its next run.
Key API Endpoints to Monitor
Product Catalog
| Endpoint | What to Assert |
|---|---|
| GET /products | Products array not empty |
| GET /products/:id | Product data complete |
| GET /categories | Categories exist |
| GET /search | Results match query |
Inventory
| Endpoint | What to Assert |
|---|---|
| GET /inventory/:sku | Quantity is valid number |
| GET /availability | Stock status accurate |
| POST /reserve | Reservation succeeds |
Cart & Checkout
| Endpoint | What to Assert |
|---|---|
| POST /cart/add | Item added successfully |
| GET /cart | Cart totals correct |
| POST /checkout | Order created |
| GET /payment/methods | Options available |
Order Management
| Endpoint | What to Assert |
|---|---|
| GET /orders/:id | Order status valid |
| POST /orders/:id/cancel | Cancellation succeeds |
| GET /tracking/:id | Tracking data present |
Best Practices
Monitor from Multiple Regions
Assert runs every check from six regions and waits for consensus before it alerts, so one bad network hop doesn't page anybody. It also tells you when only your EU shoppers are seeing the slow catalog.
Set Appropriate Intervals
You pay per monitor, not per check, and every plan goes down to 30-second intervals. Tightening a schedule costs nothing.
- Product APIs: Every 1-2 minutes (impacts all visitors)
- Checkout APIs: Every minute (directly impacts sales)
- Inventory sync: Every 5 minutes (depends on sync frequency)
- Search API: Every 2-3 minutes (important for discovery)
Create Alert Hierarchies
A dead checkout deserves a page at 3am. A slow inventory read does not:
| Severity | Alert To | Example |
|---|---|---|
| Critical | PagerDuty (immediate) | Checkout API down |
| High | Slack + Email | Product API empty results |
| Medium | Slack | Inventory API slow |
| Low | Email digest | Non-critical API warnings |
Test During Sales Events
Before Black Friday, Cyber Monday, or any major sale:
- Increase check frequency temporarily
- Add extra assertions for expected high-traffic behavior
- Test from more regions to catch CDN issues
- Lower alert thresholds for faster response
Getting Started
Start with the endpoints that cost you money when they misbehave: checkout first, then the product catalog. Write assertions against the data those endpoints return rather than the status line, route the alerts to the team that can act on them, and add endpoints as you find the next thing that broke quietly.
Related Use Cases
- Payment API Monitoring: the checkout and payment flow in detail
- Third-party API Monitoring: the vendor APIs your store calls
