Every restock monitor you have ever used, whether it is a Discord bot, a browser extension, or a mobile app, works by checking retailer APIs for product availability changes. Understanding how this process works at a technical level gives you a significant advantage. You can evaluate monitoring tools more critically, troubleshoot issues when alerts are slow, and even build simple custom monitors for niche products that mainstream tools do not cover.
This guide breaks down the technical foundations of API monitoring for restocks. It assumes basic familiarity with web technologies but explains concepts in plain language. By the end, you will understand how retailer APIs expose product data, how monitors poll those APIs, and what trade-offs are involved in different monitoring strategies.
What Is an API in the Context of Restocking?
An API (Application Programming Interface) is the way a website’s front end communicates with its back end. When you visit a product page on Nike.com, your browser does not receive the entire page as a single file. Instead, the visible page (HTML, CSS, JavaScript) loads first, and then JavaScript code on the page makes API calls to Nike’s servers to fetch product data: availability, sizes, prices, images, and stock status.
These API calls are just HTTP requests, the same technology your browser uses to load any web page. The difference is that API responses return structured data (usually JSON) rather than visual web pages. This structured data is what restock monitors read.
How a Product Page Works Behind the Scenes
When you load a sneaker product page, here is a simplified sequence of what happens:
- Your browser requests the HTML page from the server.
- The HTML page loads JavaScript code.
- The JavaScript code makes API calls to endpoints like
/api/product/12345or/product-feed/v2/sneaker-name. - The API returns JSON data containing product details, including an availability field like
"available": trueor"stockLevel": "IN_STOCK". - The JavaScript renders this data into the visual product page you see.
A restock monitor skips steps 1, 2, and 5. It directly calls the API endpoint from step 3 and reads the data from step 4. This is faster, uses less bandwidth, and can be done programmatically at regular intervals.
Common Retailer API Patterns
Different retailers structure their APIs differently, but most follow common patterns. Understanding these patterns helps you know what kind of data is available and how monitors extract it.
Product Availability Endpoints
| Retailer Type | Typical Endpoint Pattern | Response Format | Authentication |
|---|---|---|---|
| Nike | /product_feed/rollup_threads/v2/ | JSON with availability per size | None for public data |
| Shopify stores | /products/product-handle.json | JSON with variant-level inventory | None for public data |
| Best Buy | /api/tcproduct/model.json?paths=... | JSON with fulfillment options | API key in URL |
| Target | /redsky_aggregations/v1/pdp/client?... | JSON with store and online availability | None, but CORS-restricted |
| Amazon | No clean public API | HTML scraping required | N/A |
| Adidas | /api/products/ + product code | JSON with availability and sizes | Session-based |
Shopify: The Most Monitor-Friendly Platform
Shopify powers thousands of boutique sneaker and streetwear stores, and its product API is the easiest to monitor. Every Shopify store exposes a public JSON endpoint:
https://store-name.com/products/product-handle.jsonThis endpoint returns detailed product data including:
- Product title, description, and images
- All variants (sizes, colors) with individual availability status
- Inventory quantities (if the store has not disabled this)
- Price and compare-at price
- Timestamps for creation and last update
A second useful Shopify endpoint is the collection or “all products” feed:
https://store-name.com/products.json?limit=250This returns up to 250 products from the store, allowing a single API call to check availability across the entire catalog. For stores with more than 250 products, pagination is supported via ?page=2&limit=250.
Monitors that track Shopify stores typically check the products.json endpoint at regular intervals and compare the results to the previous check. If a previously unavailable variant becomes available, an alert is triggered. Many of the tools in our restock monitor tools guide use this exact approach for Shopify stores.
Nike: Layered API Architecture
Nike’s API is more complex than Shopify’s. Product data is distributed across multiple endpoints:
- Product feed — Returns general product information, images, and descriptions.
- Availability service — Returns real-time stock levels by size and channel (SNKRS, Nike.com, Nike app).
- Launch data — Returns information about upcoming drops, draw status, and entry windows.
Nike’s APIs are generally accessible without authentication for basic product data, but they implement rate limiting, geographic restrictions, and occasionally require session tokens for availability queries. Monitors that track Nike typically poll the availability service at intervals of 5 to 15 seconds and compare results between polls.
Best Buy: API Key Requirements
Best Buy offers a developer API program that provides structured access to product data, including availability. However, the developer API has strict rate limits (5 requests per second) and requires registration. Most restock monitors targeting Best Buy use a combination of the developer API for product data and browser-level requests (mimicking a real user) for real-time availability checks.
Polling Strategies
Polling is the act of repeatedly checking an API endpoint for changes. How you poll determines the speed, reliability, and resource cost of your monitoring.
Fixed Interval Polling
The simplest approach: check the API every X seconds.
while true:
response = check_api(product_url)
if response.available and not previously_available:
send_alert()
previously_available = response.available
wait(interval)| Interval | Checks per Minute | Detection Speed | Server Load | Risk of Rate Limiting |
|---|---|---|---|---|
| 30 seconds | 2 | Slow | Very Low | None |
| 15 seconds | 4 | Moderate | Low | None |
| 10 seconds | 6 | Good | Low | Minimal |
| 5 seconds | 12 | Fast | Moderate | Low |
| 3 seconds | 20 | Very Fast | High | Moderate |
| 1 second | 60 | Near Real-Time | Very High | High |
For personal use, polling every 5 to 10 seconds provides a good balance between speed and resource usage. Going below 3 seconds significantly increases the risk of being rate-limited or blocked by the retailer.
Adaptive Polling
A smarter approach adjusts the polling interval based on context:
- Normal hours: Poll every 30 seconds. Most restocks happen during business hours.
- Known drop window: When a drop is expected within the next hour, increase to every 5 seconds.
- Active restock detected: When a product shows signs of restocking (stock numbers changing, page updates), increase to every 2-3 seconds.
- Off hours: Poll every 60 seconds or pause entirely overnight.
Adaptive polling reduces unnecessary API calls while still catching restocks quickly when they are most likely to happen. This approach is used by most professional-grade monitoring services, including those discussed in our DIY restock monitor guide.
Webhook-Based Monitoring
Some platforms support webhooks, where instead of you checking the API, the API pushes updates to you. Shopify stores can configure webhooks that fire when inventory changes. However, webhooks are typically only available to store owners, not external monitors. For public monitoring, polling remains the standard approach. Our webhook notification setup guide covers how to use webhooks on the notification delivery side.
Rate Limiting and How to Handle It
Every retailer implements some form of rate limiting to protect their servers from excessive traffic. Understanding rate limits is critical for reliable monitoring.
Common Rate Limiting Mechanisms
| Mechanism | How It Works | How You Know You Have Been Limited |
|---|---|---|
| HTTP 429 Too Many Requests | Server returns a 429 status code with a Retry-After header | Explicit error response |
| Soft throttle | Server delays responses instead of blocking | Response times increase from 200ms to 2-5 seconds |
| IP block | Server stops responding to requests from your IP | Connection timeouts or 403 Forbidden errors |
| CAPTCHA challenge | Server returns a CAPTCHA page instead of API data | Response body contains CAPTCHA HTML instead of JSON |
| Cloudflare challenge | CDN-level protection intercepts requests before they reach the API | Response contains Cloudflare challenge page |
Handling Rate Limits Gracefully
When your monitor detects a rate limit, the correct response is to back off, not to push harder. Here is a recommended approach:
- Detect the limit. Check for HTTP 429 responses, unexpected HTML in JSON endpoints, or dramatically increased response times.
- Implement exponential backoff. When limited, double your polling interval. If you were checking every 5 seconds, switch to 10, then 20, then 40. This gives the server time to remove you from its rate limit list.
- Respect Retry-After headers. If the server includes a Retry-After header, wait at least that long before your next request.
- Rotate user agents. Some rate limiters track requests by user agent string. Using a realistic, rotating user agent string (not randomized nonsense) can help avoid detection.
- Use conditional requests. If the API supports ETag or If-Modified-Since headers, use them. These headers tell the server to only send data if it has changed since your last request, reducing bandwidth and signaling that you are a well-behaved client.
Ethical Considerations of API Monitoring
Monitoring public APIs at reasonable intervals is generally considered acceptable by the restocking community. You are making the same requests that a browser would make if you manually refreshed the page. However, there are ethical boundaries, as discussed in our restock automation ethics article:
- Do not hammer servers. Polling faster than once per second is excessive for personal monitoring and can contribute to site instability during high-traffic drops.
- Do not bypass authentication. If an API requires login or an API key, do not try to access it without proper credentials.
- Do not scrape data for commercial use. Monitoring for personal purchasing is different from scraping product data to build a competing service.
Building a Simple API Monitor
For technically inclined restockers, building a basic API monitor is a rewarding project that gives you complete control over what products you track and how you receive alerts.
Architecture Overview
A minimal restock monitor needs three components:
- Poller — Makes periodic API requests to check product availability.
- State tracker — Remembers the last known state of each product to detect changes.
- Notifier — Sends alerts when a product changes from unavailable to available.
Technology Choices
| Component | Beginner-Friendly Option | Advanced Option |
|---|---|---|
| Language | Python | Node.js, Go |
| HTTP client | requests library | aiohttp (async), got (Node) |
| State storage | JSON file on disk | Redis, SQLite |
| Notifications | Discord webhook | Multi-channel (Discord + SMS + push) |
| Hosting | Your own computer | VPS (DigitalOcean, Linode) or Raspberry Pi |
Core Logic for a Shopify Monitor
The fundamental logic for monitoring a Shopify store’s product availability follows this pattern:
- Fetch
products.jsonfrom the target store. - Parse the JSON response and extract each variant’s availability status.
- Compare current availability against the previously stored state.
- If any variant changed from unavailable to available, trigger a notification.
- Update the stored state with current data.
- Wait for the polling interval and repeat.
Error Handling Best Practices
Robust monitors handle failures gracefully:
- Network timeouts: Set a reasonable timeout (10 seconds) for each request. If the request times out, log the error and continue to the next poll cycle. Do not crash.
- Invalid JSON: Sometimes API responses are corrupted or the server returns HTML error pages instead of JSON. Wrap JSON parsing in try/catch and skip invalid responses.
- API changes: Retailers occasionally change their API structure. If your monitor starts receiving responses with unexpected fields or missing data, log the full response for debugging and send yourself an alert.
- Server errors (5xx): These indicate retailer server issues, not problems with your monitor. Implement exponential backoff on 5xx errors and resume normal polling when the server recovers.
Advanced Monitoring Techniques
Multi-Endpoint Correlation
For retailers with multiple API endpoints, correlating data across endpoints can give you earlier detection of restocks.
For example, with Nike:
- The product feed might update with new images or descriptions before the availability service shows stock.
- Launch data might show a new entry window before the product appears on the main feed.
By monitoring all three endpoints and correlating changes, you can sometimes detect a restock 30 to 60 seconds before availability-only monitors catch it.
Stock Level Tracking
Some APIs (particularly Shopify) expose actual inventory quantities, not just a boolean available/unavailable flag. Tracking stock levels over time reveals patterns:
- Gradual decrease: Normal sales, no urgency.
- Sudden spike: Restock just happened, alert immediately.
- Oscillation: Stock being added and removed as the retailer prepares for a drop.
- Zero to low number: Small restock, likely to sell out quickly.
Latency Monitoring
The time it takes for an API to respond can itself be an indicator of restock activity. During high-traffic events:
- Response times spike as servers handle increased load.
- New server infrastructure may come online (detectable through DNS changes).
- CDN caching behavior may change, serving stale data to reduce load.
Tracking response latency alongside availability data helps you understand whether a “sold out” response is genuine or whether the server is returning cached data from before a restock.
Monitoring Infrastructure
Self-Hosted vs Cloud-Hosted
| Factor | Self-Hosted (Your PC) | Cloud-Hosted (VPS) |
|---|---|---|
| Cost | Free (uses your existing hardware) | $5-$20/month for a basic VPS |
| Uptime | Only runs when your computer is on | 99.9%+ uptime |
| Latency to retailers | Depends on your home internet | Can be placed near retailer data centers |
| Maintenance | You manage everything | You manage the software, hosting provider manages hardware |
| IP reputation | Residential IP (generally trusted) | Data center IP (may be flagged more easily) |
For casual monitoring of a few products, running on your own computer is perfectly adequate. For serious monitoring of multiple products across multiple retailers around the clock, a small VPS provides reliability that a home setup cannot match.
Raspberry Pi as a Monitor
A Raspberry Pi makes an excellent dedicated monitoring device. It is inexpensive, runs 24/7 with minimal power consumption, and is powerful enough to handle monitoring dozens of products simultaneously. The Raspberry Pi 4 or 5 with Python or Node.js is the most popular setup in the restocking community.
Notification Delivery
The fastest monitor in the world is useless if the notification does not reach you in time. Here is how different notification channels compare:
| Channel | Average Delivery Time | Reliability | Setup Difficulty |
|---|---|---|---|
| Discord webhook | 1-3 seconds | High | Easy |
| Telegram bot | 1-2 seconds | High | Easy |
| SMS (via Twilio) | 3-10 seconds | High | Moderate |
| Push notification (via Pushover) | 2-5 seconds | High | Easy |
| 10-60 seconds | Moderate (spam filters) | Easy | |
| Browser notification | Instant | Only when browser is open | Easy |
Most monitors use Discord webhooks as the primary notification channel because of the combination of speed, reliability, and ease of setup. Adding SMS as a backup for high-priority products provides redundancy. For more on building a notification stack, see our restock notification stack guide.
Debugging Common Issues
”My Monitor Missed a Restock”
When your monitor fails to catch a known restock, investigate these common causes:
- Polling interval too long. If the product restocked and sold out within your polling interval, your monitor never saw it in stock. Shorten the interval for high-demand products.
- API caching. The retailer’s CDN may have served a cached response that still showed the product as unavailable. Adding cache-busting parameters to your requests (like a timestamp query parameter) can help.
- Geographic restrictions. Some APIs return different data based on the requesting IP’s geographic location. If your monitor runs from a different region than your actual location, it may see different availability.
- API endpoint changed. Retailers update their APIs without notice. If your monitor is hitting an outdated endpoint, it may receive stale or empty data.
”I Keep Getting Rate Limited”
If you are consistently hitting rate limits:
- Reduce your polling frequency. Start at 15-second intervals and only increase if needed.
- Check whether you are making redundant requests. If your monitor checks both the product page and the API endpoint, you are doubling your request rate.
- Verify that your monitor properly handles errors. A monitor that retries failed requests immediately (without backoff) can spiral into hundreds of requests per second.
”Notifications Are Delayed”
If you detect a restock in your logs but the notification arrived late:
- Check your notification service’s status page. Discord, Telegram, and push services occasionally experience delivery delays.
- Verify that your monitor sends notifications asynchronously. If it waits for the notification to be delivered before continuing to poll, a slow notification delivery can delay subsequent checks.
FAQ
Is API monitoring legal?
Accessing publicly available API endpoints is generally legal. You are making the same requests that a web browser makes when loading a product page. However, violating a website’s terms of service by making excessive requests or bypassing access controls could create legal liability. The key is to behave like a polite client: respect rate limits, do not bypass authentication, and do not use the data for purposes beyond personal purchasing. This is not legal advice — consult an attorney if you have specific concerns.
How fast do I need my monitor to be to catch restocks?
For most products, a 5 to 10 second polling interval is sufficient. The vast majority of restocks remain available for at least 30 seconds to several minutes. Only the most hyped products (limited sneakers, GPU launches at MSRP) sell out in under 10 seconds. For those products, a 3 to 5 second interval paired with fast notification delivery gives you a reasonable chance.
Can retailers detect that I am using an API monitor?
Yes, retailers can distinguish between browser requests and direct API requests based on headers, request patterns, and behavior. However, most retailers tolerate low-frequency API monitoring because it is indistinguishable from normal browser behavior at that rate. The risk increases with request frequency. Monitoring once every 10 seconds from a residential IP with realistic headers is virtually undetectable. Monitoring once per second from a data center IP with minimal headers is easily flagged.
Should I use proxies for API monitoring?
For personal monitoring of a small number of products, proxies are unnecessary. A residential IP with reasonable polling intervals will not trigger rate limits on most retailers. Proxies become relevant when monitoring many products simultaneously (50+) or polling at high frequency. If you do use proxies, residential proxies are far less likely to be blocked than data center proxies, but they are also more expensive.
What programming language is best for building a restock monitor?
Python is the most popular choice for beginners because of its readable syntax and extensive library ecosystem. The requests library makes HTTP calls simple, and discord.py or raw webhook calls make notification delivery straightforward. For more advanced monitors that need to handle many concurrent requests efficiently, Node.js with async/await or Go with goroutines provide better performance. The language matters less than the architecture — a well-designed Python monitor will outperform a poorly designed Go monitor.
