How do bots abuse store APIs that were built for mobile apps?

An API is a storefront without the shop floor

A mobile app needs endpoints for product data, search, stock, accounts, and checkout. Those endpoints return tidy structured data with no ads, images, or page weight. For an operator, that is the whole store as a feed, plus the ability to act on it programmatically.

Website defenses often never see this traffic. Bot checks that live in the web page, JavaScript challenges, and browser fingerprinting are all bypassed when the request never loads a page at all. The API answers, because answering is its job.

How attackers learn the API

App traffic can be inspected with standard proxy tools by anyone who installs the app. Within an afternoon, an operator can map the key endpoints, the tokens they expect, and the order of calls a real purchase makes. Published app packages and leaked documentation speed that mapping up further.

Stores then face traffic that is technically valid: correct endpoints, correct format, plausible app versions. The difference from real app users sits in volume, timing, and breadth: scraping the whole catalog, checking stock constantly, or testing thousands of accounts against the login endpoint.

The abuse menu runs through the API

Price and stock scraping, credential stuffing, gift card balance checking, coupon validation, and scalping purchases all run well over APIs, usually faster and cheaper than through the website. Some of the worst account takeover waves arrive through app endpoints that were given weaker login controls than the website got.

Inventory data deserves special care. A real time stock endpoint is a gift to scalpers deciding which drop to target and to competitors watching your supply. Data the business treats as operationally handy can be strategically sensitive.

Defenses that belong at the API layer

Give the API its own controls: per token and per account rate limits, behavior analytics on call sequences, attestation that a request comes from a genuine app instance where the platform supports it, and login protections at least as strong as the website. Rotate and expire tokens properly, and treat old app versions as a risk signal rather than a compatibility promise.

Reduce what the API reveals to unauthenticated callers. Stock precision, bulk catalog export patterns, and balance checks can require sign in and tighter limits without hurting real app shoppers, who query a handful of products rather than the entire catalog.

Why this gap keeps reopening

Web and app teams often sit in different parts of the company, ship on different schedules, and buy different security tools. The attacker does not respect that org chart. They test both surfaces and route everything through whichever one is softer that quarter.

The fix starts with one inventory and one standard: every endpoint that can read sensitive data or move money gets the same baseline of authentication, rate limiting, and monitoring, whoever built it. API abuse thrives in the space between teams.

Keep reading: How do bots game waitlists and raffles built to make product drops fair?, How is credential stuffing different from brute force, and why do the defenses differ?, and How do bots hoard inventory at checkout without ever paying? cover the nearby cases in this series.

Frequently asked questions