BugVilla
API testing · by Oadbox
Find who can break your API before someone does
Upload the Postman or OpenAPI collection you already have — BugVilla generates seven categories of tests and runs every endpoint as every role.
At a glance
- 7 test categories
- Persona × endpoint matrix
- Versioned contract diffs
Built for
Engineering and QA teams shipping APIs that other people depend on.
Live at
bugvilla.comThe problem
BugVilla turns the API collection you already maintain into a complete test programme. Upload a Postman or OpenAPI file and it generates functional, contract, negative, boundary, security, performance and authorization suites — then runs every endpoint as every role that uses your API.
The result is a cross-persona matrix showing exactly which endpoints an admin, a member or an unauthenticated caller can reach — down to the precise cell where the wrong person got in. Upload the next version and it diffs the contract against the last, keeping every run retained and comparable.
One release on BugVilla
From Monday's upload to Friday's diff
Nobody argues about whether the endpoints work. The argument is about who can call what — and it surfaces in release week, when someone asks whether a support agent can reach the admin routes and nobody can prove it either way. This is one release on BugVilla.
What we counted first
BugVilla began with our own APIs and other people's release weeks — running collections as a second role and writing down what came back. Four numbers kept repeating:
3 in 4
Endpoints tested as one role
On the collections we ran, ours included, most requests had only ever been sent with an admin token. What a member or an anonymous caller would get back was assumed rather than checked.
6 weeks
Drift in a shared collection
The Postman file three people maintained sat six weeks and eleven endpoints behind what was actually deployed. Nobody had done anything wrong — it simply belonged to no one.
2 days
One manual pass of the matrix
Swapping tokens by hand across every protected route and recording the result in a spreadsheet took most of two working days. It stayed accurate for about a week.
4
Routes nobody remembered were public
In the codebases we sat with, four routes still answered without a token — an export, a health check that returned config, and two admin helpers. Each had been temporary once.
Counted on our own APIs and in the release weeks of teams we sat with, before BugVilla existed. Every team differs — your numbers are the first thing we ask for.
- Monday 9:40 am
The collection three people maintain
The QA lead exports the Postman collection the team has grown over two years — three people commit to it, none of them owns it. It goes into BugVilla as it stands: requests, bodies, auth headers, environment variables, read out into endpoints and methods. Nothing is rewritten by hand to keep a tool happy.
- Monday 10:15 am
Personas, then credentials
BugVilla finds the login request in the collection and proposes the roles it can see — admin, member. The QA lead confirms them, supplies a test credential for each, and adds the caller the collection never had: nobody at all, holding no token. The credentials go in encrypted, so no personal token is passed around.
- Monday 10:30 am
Seven suites, generated
From that one upload come seven suites — functional, contract, negative and boundary, security, performance and authorization. Nobody writes a test case. The scaffolding that would have taken a sprint, the wrong types and missing fields and expired tokens and oversized payloads, is simply there, waiting on a run.
- Monday 2:00 pm
Run 1
Every endpoint, every suite, every persona. Most of what comes back is roughly what the team expected — a handful of contract mismatches, two routes slower under load than anyone had claimed, a validation gap on an optional field. Then the authorization results finish, and the list stops being routine.
- Monday 2:40 pm
The cell that lit up
Every protected endpoint run as every persona, laid out as a grid. Most of it matches what the team believed — admin through, member denied, the anonymous caller nowhere. Then one cell in the member row, on the admin export endpoint, comes back 200: a support agent's role could pull the full customer export, and nobody in the room could say for how long.
- Wednesday
The cell gets an owner
The report goes to the backend engineer who owns that service — PDF for the release thread, JSON for the ticket, findings ordered by what to do about them rather than by endpoint. The role check on that route had been added, then dropped in a refactor, and never missed. BugVilla does not fix it; it names the cell, and the fix takes an afternoon.
- Friday
v2, and what actually moved
The corrected build ships and the updated collection goes up as v2. The contract diff against v1 states what moved — two new fields, one response gone, the export route now answering 401 to everyone but an admin. v1 stays where it is and stays re-runnable, and the whole run goes on a schedule so next release nobody has to remember.
What quietly disappears
None of this is dramatic. It is the same release week — minus the artefacts everyone had stopped noticing.
The spreadsheet of who-can-call-what
The afternoon of swapping tokens by hand
The 'we'll test roles later' ticket
The forked collection with an admin token in it
The 403 screenshot pasted into the release thread
Key workflows
What it actually runs.
Upload what you already have
Postman collections, OpenAPI and Swagger specs, or raw cURL — parsed into everything a test needs.
Personas detected, then confirmed
The login endpoint, token path and roles are detected from the collection; you supply credentials per persona.
Seven suites from one upload
Functional, contract, negative, boundary and fuzz, security, performance and authorization — generated, not written.
The authorization matrix
Every protected endpoint run as every persona. Deny is strict, allow is forgiving, and failures point to the exact cell.
Versions, not overwrites
Upload v2 and keep everything — a contract diff against v1, and any version re-runnable at any time.
Reports worth forwarding
PDF, HTML, CSV and JSON exports with findings sorted by what to do about them.
The unglamorous parts, handled
Cron-style scheduled runs, plus environments and credentials encrypted at rest.
Isolated by architecture
A dedicated database per tenant, with UI, workflow and VAPT testing on the visible roadmap.
Why Oadbox
We know the industry
BugVilla was designed inside api testing operations, not adapted from a horizontal tool.
It runs on our core
Tenancy, permissions, statutory compliance, offline mobile and audit trails are inherited, not rebuilt for each product.
Inside the platformWe still operate it
The team that built BugVilla runs it — monitoring, support, releases and the next version.
How we workMore from Oadbox
11 other products, same foundation.
Want to see BugVilla on your own data? That is the only demo worth having.
Thirty minutes with someone from the product team — how you work today, and an honest answer on whether this fits.