API abuse protection that stops attacks without breaking integrations
Your app gets credential stuffing, bulk sign-ups, bursts of API calls and injection hidden in JSON. And every badly tuned protection risks cutting off a customer’s integration. Klacos sits in front of your app and its API, watches first, then stops the abuse: customers and partners get through, and every refusal comes with a reason.
Abuse you pay for in compute, support and trust
An app on the open internet draws traffic that isn’t your users. Scripts try credentials stolen elsewhere on your login page. Others open accounts in bulk to farm a free trial. Some hammer an expensive endpoint, an export or a search, while others slip an injection into a JSON body or probe for a known vulnerability.
Each of them costs you something: compute, exposed customer accounts, support tickets. And the protection itself has a price when it gets things wrong. An integration blocked with no explanation means a customer emailing, an engineer digging through logs, and trust that takes a knock.
Every route you open and every integration you add widens what a script can try. Better to know what is hitting your API before the day a customer asks why it’s slow.
What reaches your app, and what happens to it
Klacos analyses every request before your app does, keeps pages, API calls and files apart, then applies the policy you set for each.
- A customer signed in to your app Gets through
No challenge by default: they use your app exactly as before.
- A partner calling your API Gets through, allowed
Added to your allowlist by address or network, permanently or for a set period, it gets through without being treated as a bot.
- A webhook from your payment provider Gets through, verified
Verified bots get through on the paths you declared, just like your uptime monitoring.
- Stolen credentials tried one after another Capped
Rate limiting caps login, sign-up or a single API route, each at its own pace, without shutting anything else.
- Accounts created in bulk Slowed, then checked
Their pace and behaviour don’t look like real sign-ups. Bot management slows them down, checks them without showing anything, then stops them.
- Injection in a JSON body Stopped
The web application firewall reads parameters, headers and the request body, and stops it before your code runs.
- A burst on an expensive endpoint Capped, with a retry time
The client gets a response telling it when to come back, and your server keeps its capacity for everyone else.
On an API, a refusal is never a page to fill in. It is a structured response with a reference, which your customer’s code can read.
What keeps your customers' integrations working
API protection is judged on the day you switch it on. The web application firewall inspects the path, parameters, headers and body of every request, whether it is a form, JSON, XML or a file upload. It stops SQL and command injection, XSS, server-side request forgery and known exploits, and can virtually patch a known flaw in a component you use until you update it.
It also has to let your customers, partners and providers through.
Your API observed on its own
On day one, nothing is blocked. Your API is tuned separately from pages and files, and you see what calls it before you change anything.
Every setting replayed first
You replay a rule against your past traffic and see which requests it would have refused. Then you roll it out one step at a time, with a one-click rollback.
Partners and providers recognised
Partners come in through an allowlist, permanently or for a set period. Payment webhooks and monitoring get through as verified bots, on the paths you declare.
Precise exceptions
A firewall rule fires on a legitimate parameter? Add an exception by path, parameter or rule, in one click from the event, and protection stays on everywhere else.
Refusals your customers' code can read
On the API, a refusal is a structured response with a reference, and a burst is told how long to wait. Your customer’s code knows what to do, and your support team knows where to look.
A record of every change
The audit log shows who changed which setting, and when. Roles limit who can, and logs flow to your own tools in standard formats.
Allowlists, paths reserved for certain addresses and password protection for a staging site are all covered under access rules. Log export and the read API are set out under logs and exports.
When a customer asks why, you have the answer
Every refusal carries a reference. Your customer passes it on, your support team finds it in the console and reads why the decision was made: the pace, the firewall rule, the limit that was reached. If it was a mistake, unblocking takes one click.
A visitor stopped in your app sees a page in your colours, with that reference and a link to appeal. There is more on explained decisions.
Access rules also lock away what shouldn’t be public: your staging environment behind a password, your admin area restricted to your office addresses.
A protected API your customers don’t notice
Less compute wasted
Bursts and credential stuffing hit a per-route cap, and your compute stays with your users.
Injection stopped upstream
JSON, XML and file uploads are read before your code runs: injection and known exploits stop in front of your app.
Integrations that keep running
Allowed partners, verified webhooks and precise exceptions: protection goes on without cutting off anyone who should get through.
Support that answers fast
A reference for every refusal, a reason in the console, unblocking in one click.
Everything else, from certificates to logs, is set in the same console. Running a different kind of site? See every solution side by side.
Questions from engineering teams
Will customers calling my API ever see a CAPTCHA?
No. A refusal on an API is a structured response with a reference that their code can read. There’s never a page to fill in.
Can I set different rules for my API?
Yes. Pages, API calls and files are tuned separately, and limits are set route by route: login, sign-up, an expensive export.
Does the firewall read JSON bodies?
Yes: forms, JSON, XML and file uploads, as well as the path, parameters and headers.
How do I avoid blocking a partner?
Add them to your allowlist by address or network, permanently or for a set period. And everything starts in observation: you see what would have been blocked before anything is.
Does it handle my users' authentication?
No. It protects your app and its API, but signing your users in stays with you. Nor does it deal with fraud specific to your business logic.
Do I need to change my application?
No. Klacos sits in front of it, with no script or library to add. Your server becomes the origin.
See what a rule would have refused on your API, before it goes live
Request early access: your app starts in observation, and every setting can be replayed against your past traffic. Or talk to us about your API now.