APIWatch: Checking API Traffic and Subscription Controls with WSO2 API Manager

Nusaik_Ahamath — Sun, 18 Oct 2026 19:23:30 +0000

I recently worked on a project called APIWatch using Python and WSO2 API Manager. It is a small monitoring tool that reads API traffic logs and helps review errors, slow responses and unusual traffic.

I ran the project on my laptop with a demo shop API. This post covers the setup, the problems I found and the results of my tests.

One result is worth sharing early: the machine learning model did not improve detection in my controlled incident test. The simple checks used alongside it found all four test incidents.

What APIWatch does

The demo shop has endpoints for products, orders and health checks. WSO2 API Manager sits in front of it. Requests go through WSO2 before reaching the Python backend.

WSO2 handles API access and records gateway measurements. APIWatch reads those measurements and groups them into one-minute periods, called windows.

For each window, APIWatch looks at:

The number of requests.
The share of requests that returned selected client errors, server errors or throttling responses.
The average response time.
The number of requests with a recorded response time.

These values help show when traffic changes or the API starts having problems. The saved feature files leave out access tokens, usernames, client IP addresses and response bodies.

Getting the local setup working

One problem came from the Windows folder path. WSO2 failed to start when I placed it under D:\MY PROJECTS. Moving the installation to D:\Tools fixed that startup problem.

After the gateway and backend were running, I called the products endpoint through WSO2. It returned HTTP 200 with the demo product list.

I then checked the gateway metrics log. The request appeared there with its response status and timing. This confirmed that I could collect measurements from the running local gateway.

Collecting normal traffic

Before checking unusual traffic, I needed examples of normal traffic.

A Python script sent successful GET requests at different rates. The first longer collection was planned for 55 minutes, but four one-minute windows were missing. I also left out an uncertain window just after that gap.

After review, the training data contained 50 one-minute windows and 2,491 requests.

I used these windows to train an Isolation Forest model. This model looks for patterns that differ from its training examples. Its score tells us how unusual a pattern looks; it does not tell us the chance that someone is attacking the API.

Normal traffic also raised alerts

In a later ten-minute normal session, the model flagged six windows.

That was a useful problem to investigate. The requests were part of my scripted normal test, but the model still found some patterns unusual. Small changes in response time and combinations of values could fall outside the limited training examples. I did not have enough evidence to identify the physical cause of those changes.

I used this session to calibrate how model scores turn into alerts. In simple terms, I compared new scores with scores from these normal examples. Once I used those ten windows to make that change, I could no longer use them as a fresh test.

The updated policy also included checks called guards. These check for conditions such as many error responses, a high request rate or slow responses. For the slow-response check, I used a 100 ms local lab budget, with at least five recorded response times needed.

That budget was a setting for this experiment. A different API would need its own response-time target.

Testing with fresh normal traffic

I kept the detector settings fixed and collected another ten-minute normal session with a different traffic seed.

This time, 530 sent requests matched 530 gateway events, with no missing windows. None of these windows had been used for calibration.

The original ML model, calibrated ML model, hybrid method and original simple rules each raised one false alert out of ten normal windows. The guards raised no alerts.

So I could not claim that calibration improved the result. The earlier six false alerts and the later one false alert came from different sessions. The original model also produced one false alert in the fresh session.

Ten windows are also too few to tell us how well the tool would work on production traffic.

Checking errors, delays and traffic bursts

Next, I ran a seven-minute controlled test. Each minute had one case:

Ordinary successful requests.
A legitimate traffic burst.
Backend 404 responses.
Backend 500 responses.
Delayed responses.
A request rate above the guard threshold.
A return to ordinary traffic.

The demo backend has a lab mode for creating the error and delay cases. The test script checks its marked responses so a gateway login failure cannot be mistaken for an intended backend error.

The run completed 960 requests, and all 960 matched gateway events. All seven test conditions were verified.

There were four incident windows and three normal windows. Here are the results:

Method	Incidents found, out of 4	Incidents missed	False alerts, out of 3 normal windows
Original ML	1	3	0
Calibrated ML	0	4	0
Guards only	4	0	0
Calibrated hybrid	4	0	0
Original simple rules	2	2	1

The hybrid combines calibrated ML alerts with guard alerts. In this run, every hybrid alert came from a guard. The calibrated ML model added no detections.

The legitimate burst reached 147 requests per minute. The hybrid accepted it, while the original simple rules raised a false alert.

The excessive-rate case reached 588 requests per minute, above the fixed guard threshold of 328 per minute. The slow-response case had an average gateway response time of about 304 ms, which triggered the latency guard.

The backend 404 and 500 cases triggered the matching error guards.

These were deliberately created faults and traffic conditions. Finding all four proves that the expected checks worked in this short test. It does not establish general attack-detection accuracy.

Reviewing the results in a dashboard

I also used a local dashboard to review the saved captures. It shows request rates, response times, alert reasons and comparisons between the methods.

Each alert window can be marked as Confirmed incident, Benign or Investigate, with a note. The review is saved separately from the test labels and detector results.

During my check, I reviewed all four pending alerts. The pending count became zero, while the four recorded alerts stayed visible.

The dashboard currently reads saved files. It does not continuously collect and score live gateway traffic.

Blocking and restoring a subscription

I ran a separate manual check using the APIWatchClient subscription in WSO2.

I called GET /apiwatchdemoshop/1.0.0/products, blocked the Production subscription in Publisher, tested again and then unblocked it.

Step	Result
Before blocking	HTTP 200 with the demo products
While blocked	HTTP 401 with gateway code 900907
After unblocking	HTTP 200 with the demo products again

The error code mattered here. A 401 response alone can have different causes. WSO2 documents code 900907 for a blocked subscription.

I tested through the Developer Portal using fresh Production tokens after the changes. Gateway caching can affect existing tokens, so this check did not measure how quickly every previously issued token would be affected.

I changed the subscription manually in WSO2 Publisher. The APIWatch dashboard did not perform the block. I also did not test Sandbox access or access from another application.

I kept this check separate from the seven-window detector results.

What I learned

Getting a model to produce alerts was only one part of the work. I also had to check missing data, compare sent requests with gateway records, keep calibration data separate and test on fresh traffic.

The most useful comparison was between the hybrid method and the guards alone. Both found the same four incidents in this run. Reporting that result gives a clearer picture of what the ML model contributed.

APIWatch is still a local lab project. Further work could include longer tests, different traffic patterns and continuous collection. Automatic response actions would need separate implementation and testing.

For now, the project shows a working WSO2 integration, traffic collection, detector comparisons, manual alert reviews and a checked subscription block-and-recovery flow.

About AI assistance: I used AI tools to help with coding and writing. I ran the WSO2 setup, traffic collection, dashboard reviews and subscription checks manually. The numbers in this post come from those saved lab results.

Source code and setup guides: APIWatch on GitHub.

References

WSO2 API Manager error handling — reference for gateway code 900907.
WSO2 subscription blocking and unblocking — procedural reference, including token-cache considerations.
scikit-learn IsolationForest documentation — reference for the model.

DEV Community: Nusaik_Ahamath