Evaluate API abuse prevention on three questions: does it tell your genuine app apart from scripts and altered clients, does it leave legitimate automation untouched, and does it enforce without hurting availability. Otukan is built to answer all three. The protected app attaches client evidence to sensitive calls, your gateway or backend verifies it, and each endpoint follows rate, challenge, retry and failure rules you write. Scope is misuse of endpoints built for your app, such as scraping, offer abuse and enumeration, on Android and iOS, with evidence labelled per platform.
For the wider trust model behind this control, see mobile API protection.
Abuse path
Abuse rarely looks like an attack. Each request is well formed, authenticated where needed and within the published contract. What gives it away is who is calling and why. Otukan sorts callers into three groups before your business logic runs.
| Caller | What it looks like at the gateway | How Otukan helps you treat it |
|---|---|---|
| Automated requests | A script or headless client replaying the app’s calls at volume | No valid evidence from your released app, so verification fails and your rule applies |
| Invalid clients | Your own app, repackaged, hooked or driven by tools on an emulator | Evidence arrives, but integrity or environment checks report the change |
| Legitimate automation | Partner integrations, uptime monitors, your QA farm and load tests | Registered in advance and routed to its own rules, so it stays apart from abuse |
Per-platform evidence
Genuine-client evidence differs between Android and iOS, because each platform exposes different facts to an app. Otukan scopes each signal to its platform and labels it, so a gateway rule written for Android traffic is never silently applied to iOS traffic.
Where abuse concentrates
Search and catalogue reads attract scrapers. Offers, referrals and loyalty endpoints attract redemption farms. Sign-up, login and password reset attract enumeration. Reservation and basket calls attract hoarding. Otukan’s rollout ranks these endpoints by the harm a scripted caller could do, because the right rule for a price lookup is not the right rule for a voucher.
Enforcement boundary
A good design puts each decision where it is hardest to tamper with and cheapest to run.
In the app
The protected app gathers evidence: that it is your unmodified release, which environment it runs in and whether tools are attached. It does not decide whether abuse is happening, because code on a device an attacker controls can be studied.
At the gateway
Your API gateway verifies the evidence on each sensitive call and applies the endpoint’s tier: allow, slow down, challenge or refuse. This is where volume rules become client-aware rules, with generous limits for verified app traffic and tight ones for callers that cannot prove their origin.
In the backend
Business services see the verified result and add account context: redemption history, sign-up velocity, order patterns. Decisions that need that context, such as holding a suspicious redemption for review, belong here. Otukan labels each evidence source so the backend knows what every result proves.
Continuity
Enforcement that breaks the app on a busy day is worse than none. Otukan documents four policies per endpoint before anything is switched on.
- Rate. Separate limits for verified app traffic, registered automation and unverified callers.
- Challenge. What an unverified caller must do to continue, and how the app presents that step to a real person.
- Retry. How the app retries a challenged or refused call, with back-off, so a real user does not loop and your gateway is not flooded.
- Failure. What happens when verification itself is unavailable: continue and record, challenge, or wait, chosen per tier.
Proving it before enforcement
Otukan works with your team to prove each rule three ways. Reproduce the abuse case in an authorised lab and confirm the gateway sees it. Run the same journey from a legitimate app on a supported device and confirm it passes quietly. Then repeat install, update, sign-in and the endpoint’s own flow on the protected release. Results are recorded with app versions, devices, expected outcomes and the reviewer, and rules move from observe to enforce one tier at a time.