Start with contract testing, because it is the highest-leverage and the most commonly missing. Call the deployed API and assert that every response validates against the schema in your definition, that status codes match what you documented, that required fields are present, that types are right. This is what catches the gap between what you promised and what you ship, and it is the difference between a definition that is a contract and one that is decoration.
Then functional testing: does the operation do the right thing, does the business logic hold, does state change as expected across a sequence of calls.
Then the unhappy paths, which is where most API test suites are thin. Invalid input, missing required fields, wrong types, oversized payloads, expired credentials, insufficient scopes, another tenant’s object ID, rate limit exceeded, and the same request twice. Happy-path bias is the norm, and it is why error responses so often turn out to be undocumented or inconsistent — nobody ever exercised them.
Add security tests for authorization on every operation, not just a sample. And add performance tests against whatever latency you have committed to.
Run all of it in the pipeline against a real deployment, not only against a mock. A mock built from your definition will happily agree with your definition forever.
