API Monitoring Guide
Get alerted when Shopify API has issues before your customers notice broken inventory sync, failed orders, or checkout errors. Know the Shopify API status in real time, not 15 minutes later.
Shopify powers millions of online stores and processes billions in transactions every year. When their API slows down or goes offline, order processing stops, inventory sync breaks, fulfillment integrations fail, and your revenue is directly impacted.
This guide covers everything you need to know about monitoring Shopify API status: which endpoints to track, how to handle rate limits and API versioning, how to set up alerts, and what to do when Shopify goes down during a critical sales event.
Shopify maintains their own status page at shopifystatus.com. While it's a useful reference, relying on it as your only source of Shopify API status has critical gaps.
External synthetic monitoring catches Shopify API issues in 1-2 minutes, not 10-15. During high-traffic events, that head start lets you switch to cached data, pause operations, or notify your fulfillment team before customers are impacted.
Shopify releases new API versions quarterly and deprecates old ones on a rolling schedule. Understanding this is critical for monitoring because using an unsupported version will cause your API calls to fail -- and your monitors need to use the right version too.
Always use a supported API version in your monitor URLs. When you migrate your app to a new API version, update your monitor endpoints to match. If you use an unsupported version, Shopify will return errors that look like outages but are actually version deprecation issues.
Shopify also has an "unstable" version (unstable) that includes upcoming features but can change without notice. Never use the unstable version for monitoring -- stick with a stable, supported version.
Focus on the endpoints critical to your store's operations. Each endpoint below tests a different part of Shopify's infrastructure, so monitoring multiple endpoints helps you pinpoint exactly what's failing.
GET https://{store}.myshopify.com/admin/api/2025-01/shop.json
Shop info endpoint. The simplest health check that confirms the Shopify Admin API is responding and your authentication is working. Returns basic store details like name, domain, and plan. This should be your primary health check endpoint.
GET https://{store}.myshopify.com/admin/api/2025-01/orders.json?limit=1
Orders endpoint. Critical for fulfillment integrations and order processing workflows. If this endpoint fails, new orders won't sync to your fulfillment system, OMS, or ERP. Use ?limit=1 to minimize API cost.
GET https://{store}.myshopify.com/admin/api/2025-01/products.json?limit=1
Products endpoint. Monitor to ensure catalog sync works across channels (marketplace listings, comparison shopping engines, social commerce). If product sync breaks, you risk listing stale prices or out-of-stock items.
GET https://{store}.myshopify.com/admin/api/2025-01/inventory_levels.json
Inventory levels. Essential for preventing overselling when you manage inventory across multiple channels or locations. A failure here means inventory counts can drift, leading to overselling or phantom stock.
GET https://{store}.myshopify.com/
Your storefront. Monitor the customer-facing site for availability. The Admin API and storefront can fail independently -- customers may be unable to browse or checkout even if the Admin API is fine, and vice versa.
Rate limit note: Shopify's REST API allows 40 requests per app per store per second (leaky bucket, restored at 2/second). Use ?limit=1 on list endpoints to minimize API cost. UptimeSignal's monitoring requests are minimal compared to this budget -- even at 1-minute intervals, you're using less than 1 request per minute per endpoint.
Understanding Shopify's rate limiting system is essential for both building robust integrations and setting up effective monitoring. Hitting rate limits can look identical to an outage from your application's perspective.
Shopify uses a leaky bucket algorithm for the REST API. Your bucket holds 40 requests, and 2 leak out (are restored) per second. This means you can burst up to 40 requests instantly, but sustained throughput is limited to 2 requests per second.
This header shows 32 of 40 bucket slots used. When it hits 40/40, you get HTTP 429.
The GraphQL API uses a cost-based system. You have a budget of 1,000 points with a restore rate of 50 points per second. Each query has a calculated cost based on the fields and connections requested. Complex queries with nested connections cost more.
Shopify Plus stores get higher rate limits: 80 requests in the REST bucket (restored at 4/second) and 2,000 points for GraphQL (restored at 100/second). If you're on Plus, your monitoring can be more aggressive without risk.
When Shopify returns HTTP 429, it's a rate limit, not an outage. Your monitor should be configured to alert on 429s because they indicate your integration is being throttled, but the response is different from a 503 Service Unavailable which indicates actual Shopify infrastructure problems. UptimeSignal tracks both status codes and response times, so you can see the difference at a glance.
Understanding common failure patterns helps you configure monitoring that catches real problems quickly and avoids false alerts.
During BFCM, flash sales, or viral product launches, Shopify API response times can spike from the normal 200-500ms to 2-5 seconds or more. Your integration may time out before Shopify responds. Monitor response times and set thresholds at 3 seconds to catch degradation before it becomes a full outage.
Shopify access tokens can be revoked if an app is uninstalled and reinstalled, or if app permissions change. Your monitoring will catch this as a 401 Unauthorized response, alerting you to fix the authentication before your integration goes silent.
Shopify webhooks can silently fail. If your webhook endpoint returns a non-2xx status, Shopify will retry with exponential backoff and eventually disable the webhook after 19 consecutive failures. Use CronSignal to monitor that expected webhooks are arriving on time.
When an API version reaches end-of-life, Shopify starts returning errors instead of data. This usually happens 12+ months after a version's release. Your monitoring catches this immediately as a non-200 response, giving you time to update before your production integration breaks.
Shopify's infrastructure is segmented. The checkout system, Admin API, Storefront API, and webhook delivery can fail independently. A problem with the checkout system may not affect the Admin API, and vice versa. Monitor each critical path separately to know exactly what's impacted.
In Shopify Admin, go to Settings → Apps → Develop apps. Create a custom app and configure the Admin API scopes you need (use read-only scopes for monitoring: read_orders, read_products, read_inventory). Install the app and copy the Admin API access token.
Security tip: Create a dedicated app for monitoring with minimal read-only scopes. Don't reuse your production app's token.
Sign up at app.uptimesignal.io and add a new HTTP monitor with these settings:
Replace {store} with your Shopify store name and shpat_your_token with your actual access token.
Repeat step 2 for each critical endpoint. At minimum, monitor the shop endpoint (API health), orders endpoint (fulfillment), and your storefront URL (customer-facing). Each uses the same access token header.
Set up alerts that reach the right people:
Before major sales events, upgrade to 1-minute check intervals (Pro plan) and add monitors for inventory and product endpoints. The faster you detect issues during peak traffic, the more revenue you protect.
Configure your monitors to alert on these conditions:
For the shop endpoint, check for "shop" in the response body. This confirms the API returned valid JSON data and not an error message, maintenance page, or HTML error from a reverse proxy. Body validation catches edge cases that status code checking alone can miss.
When your monitoring alerts you to a Shopify API issue, here's how to respond quickly and minimize revenue impact.
Check shopifystatus.com and the Shopify Community forums. Determine if the issue is platform-wide or specific to your store/app. Check if it's a rate limit (429), auth issue (401), or actual outage (500/502/503). Each requires a different response.
If your catalog sync is broken, serve product data from your local cache. This keeps your external sales channels (marketplaces, social commerce, comparison engines) running while Shopify recovers. Ideally, you've implemented this caching layer before an outage occurs.
If order processing is affected, queue incoming orders for retry. Implement idempotency keys to prevent duplicate orders when the API recovers. If you process orders from multiple channels, prioritize the queue by order value or fulfillment urgency.
Disable automatic inventory adjustments during the outage. Sending inventory updates that fail silently can cause stock levels to drift, leading to overselling or phantom stock when the API recovers. Resume sync carefully after recovery and reconcile counts.
Alert your warehouse, 3PL providers, and fulfillment partners about potential delays. Update your status page so customers know about any order processing delays. Proactive communication reduces support ticket volume significantly.
curl -H "X-Shopify-Access-Token: YOUR_TOKEN" https://YOUR_STORE.myshopify.com/admin/api/2025-01/shop.json. For continuous automated monitoring, set up UptimeSignal to check every 1-5 minutes and alert you instantly when the Shopify API status changes.
/admin/api/2025-01/shop.json as a general health check. Add the orders endpoint if you depend on order sync, the products endpoint for catalog integration, and your storefront URL for customer-facing availability. Use ?limit=1 on list endpoints to minimize API cost and stay within rate limits.
Retry-After header. Monitoring at 1-5 minute intervals uses negligible rate limit budget.
Add Shopify to your monitors and get alerted on issues instantly. Know your Shopify API status before your customers do.
Start monitoring free →No credit card required. 25 monitors free. Commercial use allowed.