Why your API needs a front door (WSO2 API Manager)
Why I used WSO2 API Manager
I built an online voting app called VoteSecure. It has a React website, a Spring Boot backend and a PostgreSQL database. At first, the website called the backend directly. That works, but I soon had four worries:
- Someone could call my API a million times a minute.
- I could tell which user was calling, but not which app.
- If I changed an endpoint, older apps could stop working.
- I could not see who was using my API, or how much.
I did not want to write code for all of this inside my backend. WSO2 API Manager does it for me. It sits in front of the backend like a front door: every request goes through it first, and it checks the request before letting it in. That is why I chose it. This post explains what it does and what I learned, in simple words.
What WSO2 API Manager is
Think of a building with a security desk at the entrance. Visitors show their ID, the guard checks it, and only then can they go in. An API gateway is the security desk for your backend. WSO2 API Manager is a free, open-source tool that gives you one, and it also helps you create, publish and watch your APIs.
On a normal local install, the Publisher and Developer Portal use port 9443, and the gateway uses port 8243 over HTTPS.
Get Isranjan sathiyaseelan’s stories in your inbox
Join Medium for free to get updates from this writer.
You can download WSO2 API Manager from the official releases page.
What the gateway gives you
The gateway does five jobs, so my backend does not have to.
1. It controls who can come in
Without a gateway, anyone who knows your URL can try your endpoints. With WSO2, only an app that has subscribed to the API and has a valid token can call it. If the token is wrong or missing, WSO2 stops the request and sends back an error code such as 900901 (invalid credentials) or 900902 (missing credentials). The backend never sees it.
2. It limits how often you can call
You do not write any rate-limiting code. You pick a plan (Bronze, Silver, Gold or Unlimited) for each app. If an app sends too many requests, WSO2 stops it with error 900800 and HTTP 429. This matters for a voting app, because the vote endpoint stays safe from floods of requests. Use the Unlimited plan while you build, and try real limits when you test for production.
3. It gives developers a place to learn and test
The Developer Portal shows each API with its documentation. People can subscribe, create keys and tokens, and test calls in the API Console without writing code. I use it the most: I create a test key, open POST /api/auth/login, click Try it out, and in about 30 seconds I know if the gateway and backend work.
4. It handles versions
Every API has a name and a version. Mine is /votesecureapi/1.0.0. Apps that use 1.0.0 keep working while I release 2.0.0. Later I can retire the old version slowly, so nobody's app breaks overnight.
5. It shows what is happening
Every request goes through one place, so you can see which APIs and apps are used, and how often. The error codes also tell you which layer rejected a request, and a wire log shows exactly what passed through the gateway.
Two layers of security
Think of two locks on the same door. The gateway checks the app, and Spring Boot checks the user. You need both, because one cannot do the other’s job.
How a request flows
A request first passes the gateway’s checks for the app. Then Spring Boot checks the user and their organization’s data. In VoteSecure, the React app sends POST /votesecureapi/1.0.0/api/auth/login to the Vite dev proxy. The proxy forwards it to https://localhost:8243. The gateway then passes valid requests on to /api/auth/login on the backend.
What I learned
Here are a few small things to remember about WSO2 API Manager:
- The gateway sits between the client and the backend. The client sends requests to WSO2, and WSO2 forwards them to the backend. The backend can also call WSO2 separately if needed.
- You can use two headers for two tokens. Use
X-APIM-Authorizationfor the WSO2 access token andAuthorizationfor the user's JWT. WSO2 must be set up to read these headers and pass the user's JWT on to Spring Boot. - Access tokens expire after one hour by default. You may be able to change this for development, depending on your WSO2 setup and permissions.
- Sandbox and Production keys can be different. Use the right key for the environment you are testing. How it behaves depends on the type of key or token.
- Never put secret tokens in frontend code. Variables that start with
VITE_are visible in the browser. Keep your WSO2 application credentials in the Spring Boot backend, and let the backend call WSO2 securely. Also protect your backend so others cannot misuse it.
Do you need one?
A gateway is not free. It is one more service to run, set up and protect, so for a tiny project with one trusted client it may be too much. I would use WSO2 API Manager when:
- Many apps or teams will use your API
- You need rate limits, quotas or plans
- You want versions and a managed life cycle for your API
- You want one place for security rules across many backends
Adding a gateway to VoteSecure made my API safer and easier to manage, and I did not have to change the backend’s business logic. It is also a great way to learn how real API platforms work.
See the full setup checklist in the VoteSecure README.
Have you used an API gateway? I’d love to hear what you ran into.
Try it yourself
The full project, including the README with the complete WSO2 setup checklist, is on GitHub:
If you’re learning API management, I’d recommend this exact exercise: take a small project you already have, put a gateway in front of it, and break things on purpose. The error codes teach you more than the documentation does.
Questions or suggestions? Leave a comment, or open an issue on the repository.
