I’ve been thinking about where API governance should fit into an API testing workflow.
We usually focus on whether an endpoint returns the expected response, but there are other things that can go wrong even when the functional test passes.
For example:
- An endpoint exposes a new field without updating the contract
- A required authentication rule is missing
- A response doesn’t follow the agreed schema
- An API change breaks an existing consumer
- Sensitive information accidentally appears in a response
- Documentation no longer reflects the actual endpoint
- An endpoint doesn’t follow the team’s naming or versioning conventions
Some of these can probably be caught through normal API tests, while others feel more like governance checks.
I’m wondering how other QA teams draw that boundary.
Would you keep these as separate governance checks, or make them part of the API test suite?
For example:
API change → schema validation → security checks → functional tests → contract validation → CI
I’m also curious whether teams use a dedicated API governance tool for these checks or build everything into their existing Katalon/CI workflow.
What governance checks have actually caught issues for you in real projects?
And which ones turned out to be unnecessary or too noisy?
Good post about checks. 
In my experience, the boundary is less about whether a check is “governance” or “testing” and more about when and how it can be executed efficiently in the delivery pipeline.
Checks I would embed directly into the API test suite
- Schema validation: If you’re already validating the response, checking it against the expected schema adds very little overhead and immediately catches contract deviations.
- Authentication/Authorization checks: Missing auth rules are effectively functional defects and should be treated like any other test assertion.
- Basic naming/versioning standards: These can often be enforced through lightweight linting or automated validation during CI.
Checks I would keep as separate governance gates
- Breaking change detection: This usually requires comparing the current API contract with a previous version (OpenAPI diff, Pact, consumer contract validation, etc.), so it fits better as a dedicated CI stage.
- Sensitive data exposure checks: These are most effective when executed consistently across all endpoints rather than only where individual test cases happen to exist.
- Documentation vs implementation drift: Functional tests may still pass while the published API documentation becomes outdated, so a separate spec-validation process is valuable.
In most projects I’ve worked on, schema validation and auth checks live inside the regular Katalon API suite because they reuse the same request/response already under test. Governance-focused items such as contract diffing, documentation validation, and organization-wide security scans are executed as separate pipeline stages.
One governance check that has caught several real-world issues for us is contract/schema validation, especially when backend teams add, rename, or remove fields without notifying consumers. Another useful one is sensitive data scanning, which can detect accidental exposure of internal IDs, PII, or debug information before release.
We haven’t needed a dedicated governance platform so far. Reusable Katalon custom keywords, OpenAPI-based validation, and CI/CD gates have covered most governance requirements without introducing another tool to manage.
So my preference would be:
Functional Tests + Schema + Auth → CI → Contract Diff / Governance Checks → Release
That keeps the feedback loop fast while still protecting against API drift, breaking changes, and compliance issues.
Whether my views make sense?
Ich meine diesen Ablauf und die wenigen Informationen, die ich gepostet habe.
Good points. I think schema, security, and contract checks should be part of the API testing workflow and run automatically in CI.
I don’t know how this text got written in Italian language, 