API abuse bots: the attacks your storefront never sees

The API believes what it is told

A web page can check how a visitor behaves. An API request simply claims to be the app. Unless the server verifies that claim properly, any script can present itself as the official app and call the same functions, thousands of times a minute, from infrastructure that rotates addresses to stay ahead of blocklists.

That trust gap makes APIs ideal for the jobs bots do best. Price and stock scraping runs cleanly through product endpoints. Card testing hides in payment calls. Inventory checks that would take a human an afternoon of browsing complete in seconds, feeding resale decisions in near real time.

The abuse patterns that show up first

Enumeration is the classic. Sequential product, order, or account identifiers let a script walk the whole range, and each successful response confirms the pattern works. Stores discover it as unexplained API load, a partner complaining about scraped prices appearing elsewhere, or customers finding their order details known to strangers.

The second pattern is function abuse rather than data theft. Discount validation endpoints get hammered with code guesses. Gift card balance checks run in bulk. Account creation and password reset calls become tools for spam and takeover preparation. None of these requests look like attacks one at a time; the abuse is in the volume and the repetition.

Defences that fit how APIs actually work

Start with identity. App attestation and signed requests raise the cost of impersonating the official app, and per client rate limits stop one caller from behaving like ten thousand users. Limits should sit per endpoint and reflect the real app's behaviour; a product view limit that the genuine app never approaches still catches scraping easily.

Design choices help as much as tooling. Non sequential identifiers end casual enumeration. Balance and validation endpoints can answer slowly, require an authenticated session, or return less information per call. Every bit of friction placed on the machine pattern and not on the shopper pattern is a win.

Watching the API as its own surface

Stores that log API traffic separately from web traffic spot abuse weeks earlier. A dashboard showing calls per endpoint, per client, and per identifier range turns the invisible visible, and baselines from the genuine app make anomalies obvious. When the app ships an update, expect the baseline to move and note it, so real changes are not mistaken for attacks.

Finally, rehearse the response. When abuse is found, the team should know in advance which limits can be tightened without breaking the app, which keys can be rotated, and who decides. API incidents unfold at machine speed, and a plan written during the incident is usually a plan that arrives after it.

Keep reading: How do bots abuse gift card balance check pages on store sites?, How do DDoS attacks hit online stores during peak sales?, and How do scraper bots harvest store content to train rival tools? cover the nearby cases in this series.

Frequently asked questions