Test annotated APIs without writing tests in your app language.
Cat-Inspector gives QA teams a guided way to validate backend behavior. Developers allowlist the functions that are safe to test, the platform turns those functions into readable forms, and every run records clear inputs, outputs, and assertion results.
Instead of asking testers to learn internal services, payload formats, or source code, the home workspace explains what is available, how to run it, and what the expected outcome should be.
What the platform connects
From backend functions to QA-ready checks
The same catalog powers discovery, form generation, execution, and result review. That keeps product behavior, QA expectations, and developer-owned code connected.
Developer setup
Annotate
Mark the functions QA is allowed to call.
QA workflow
Author
Build cases from generated forms and assertions.
Runtime
Invoke
Run checks safely through the inspector transport.
Why teams use Cat-Inspector
One surface for catalog discovery, no-code case authoring, controlled execution, and explainable results against your allowlisted backend surface.
How it works
Two views of the same pipeline: developers keep control over what can run, while QA gets a clear workspace for building and repeating checks.
1. Developers expose safe test units
Backend developers register functions through the SDK and describe the inputs, return types, and labels that should appear in the catalog.
2. The catalog becomes the QA interface
The web app reads that metadata and turns it into understandable forms, so testers work with business inputs instead of source code.
3. Runs produce explainable results
Every invocation returns structured output, errors, and assertion results that make it easier to see what failed and why.
- Open the workspace and review the catalog synced from the host. Each entry explains what the function does and which fields are required.
- Pick a function and fill the generated form from parameter metadata, without guessing payload structure or writing request scripts.
- Set expected outcomes, run checks, and compare the response with assertions that are easy for non-developers to read.
- Save useful cases, repeat them after changes, and share failures with enough context for developers to reproduce quickly.
Questions
Quick answers for evaluators and new tenants.
