API abuse bots: why your mobile and checkout APIs get attacked even when the website looks fine

The four jobs APIs get abused for

Credential testing is the volume leader: leaked username and password pairs tried against login endpoints at a pace no human matches. Balance and validity checks come next, gift cards, promo codes, and account numbers tested one by one until live values respond differently from dead ones. Scraping follows, prices, stock levels, and product data pulled systematically for competitors or resale pricing.

The fourth job is transaction abuse itself: checkout endpoints used to test stolen cards with small purchases, reserve inventory without buying, or abuse refunds and account creation at scale. Each job has a signature in the data, usually a high failure rate, an unnatural sequence of calls, or one identifier, device, address, or payment token, appearing across many accounts.

Why page defences do not transfer

Challenges and JavaScript checks that stop page bots do nothing for a client that never loads a page. API clients present tokens and headers directly, and a bot that has copied a real app's request pattern can look convincing at the level of any single call. Defence has to move to behaviour and economics: rate and sequence analysis per identity, and making each attempt cost more than the information it returns.

Error design matters more than most teams expect. An endpoint that answers differently for a valid and an invalid gift card, account, or code is an oracle: it will be queried until it gives up its list. Uniform responses, consistent timing, and delayed confirmation through a separate channel remove the oracle without removing the feature for real customers, who rarely test values one after another.

Controls that work at the API layer

Authenticate and authorise every call as if the client were hostile, because some are: short lived tokens, per account scopes, and server side checks on every sensitive action rather than trust in the app flow. Rate limit by several keys at once, account, device, network, and payment instrument, since attackers rotate whichever single key a naive limit watches.

Add friction selectively where abuse concentrates: step up verification after failed attempts, require re authentication for payout or email changes, and queue rather than instantly confirm sensitive results. Selective friction keeps the honest majority fast while making bulk testing slow and expensive, which is the economic shift that actually ends most abuse campaigns. Attackers optimise for cheap answers.

Measure abuse before and after

Instrument the endpoints attackers love: login success and failure ratios, balance check volumes per account, code redemption attempts, and checkout declines per instrument. A healthy baseline makes campaigns visible as they start, not when finance notices chargeback drift. Track false positives with equal care, because a control that locks out travellers or shared household accounts will be quietly disabled by support within a month.

Review the data with the fraud and platform teams together. Bot defence, fraud, and API reliability are usually one problem viewed from three desks, and the attacker does not respect the org chart. The sites that handle API abuse best treat endpoint behaviour as a single signal picture, reviewed weekly, with limits tuned from evidence rather than set once and forgotten.

Keep reading: Inventory hoarding bots: how automated carts lock up stock real shoppers cannot buy, Credential stuffing attacks on retail accounts: borrowed passwords at machine speed, and Fake account creation bots: why stores drown in junk signups cover the nearby cases in this series.

Frequently asked questions