A team can build software that perfectly matches its specification and still ship the wrong product. They can also build exactly the right product on top of code riddled with defects. Those two failures have names: the first is a verification problem, the second is a validation problem. Confusing the two is how quality processes end up busy but ineffective.
This guide pins down both terms, lays out the differences, and shows where each one lands in an API testing workflow with Apidog.
What is verification?
Verification asks: are we building the product right?
It checks that a piece of software conforms to its specification, its design, and its standards. Verification compares the work against the documented intent. It does not ask whether that intent was correct; it only asks whether the implementation matches it.
Verification happens continuously, throughout development, not at the end. Typical verification activities include:
- Code reviews and walkthroughs
- Static analysis and linting
- Design and architecture reviews
- Schema and contract checks
- Unit tests that confirm a function does what its signature promises
The key trait is that verification is mostly internal. It compares an artifact against another artifact: code against design, response against schema, implementation against spec. No real user is required. If the spec says the endpoint returns a 201 with a Location header, verification confirms it does exactly that.
What is validation?
Validation asks: are we building the right product?
It checks that the software actually meets user needs and solves the real problem, regardless of what the spec said. Validation compares the work against reality and intent of use, not against a document.
Validation tends to happen later, once there is something a user or stakeholder can exercise. Typical validation activities include:
- User acceptance testing
- Beta programs and usability testing
- End-to-end testing of complete workflows
- Stakeholder demos and sign-off
The key trait is that validation is outward-facing. It asks whether the finished product is useful and correct in context. An API can pass every verification check, conform perfectly to its OpenAPI spec, and still fail validation because the spec itself solved the wrong problem; the pagination model is unusable, or the auth flow does not fit how clients actually integrate.
Validation vs verification: the differences
| Dimension | Verification | Validation |
|---|---|---|
| Core question | Are we building it right? | Are we building the right thing? |
| Compares against | Specification, design, standards | User needs, real-world use |
| Timing | Continuous, throughout development | Later, once something is usable |
| Typical methods | Reviews, static analysis, unit tests, schema checks | Acceptance testing, beta, end-to-end, demos |
| Direction | Inward: artifact vs artifact | Outward: product vs reality |
| Catches | Defects, spec deviations, contract drift | Wrong requirements, poor fit, usability gaps |
| Cost of skipping | Buggy code that matches a good spec | Polished product solving the wrong problem |
The two are not interchangeable, and neither replaces the other. Strong verification with weak validation gives you a defect-free product nobody wants. Strong validation with weak verification gives you the right idea implemented on unstable code. You need both, applied at the right time.
A simple mnemonic: verification is testing against the document, validation is testing against the purpose.
How this plays out in API testing
APIs make the distinction concrete, because an API has an explicit, machine-readable specification: its OpenAPI or schema definition. That spec is the verification baseline.
Verification for an API means checking the implementation against that contract:
- Does each endpoint return the documented status codes? Getting these consistent is a discipline of its own; see which HTTP status codes REST APIs should use.
- Does every response match the documented schema, with the right field names and types?
- Are required parameters enforced exactly as specified?
- Does the error format match the documented error shape?
This is also where API contract testing lives. A contract test is pure verification: it confirms the producer still honors the agreement that consumers depend on. API assertions on status, schema, and headers are the unit of verification work.
Validation for an API means checking whether the API genuinely serves its consumers:
- Can a client complete a real end-to-end workflow, login, create, update, delete, without awkward workarounds?
- Does the data the API returns actually answer the questions client developers ask?
- Is the auth model practical for the integrations that exist?
- Do the documented examples reflect how the API is really used?
An API test scenario that chains several requests into a complete user journey is closer to validation; a single-endpoint schema check is verification. Both belong in the suite. Understanding test scenarios vs test cases helps you see which layer you are working at.
Where Apidog fits
Apidog supports both sides of the distinction because it keeps API design, testing, and documentation in one workspace.
For verification, the API design is the specification. When you build a test, you assert responses against the same schema that defines the API, so verification has no second copy of the contract to drift away from. Schema assertions, status assertions, and contract checks all run against the source of truth. Run them on every commit through CI; automating API tests in CI/CD makes verification continuous, which is exactly when it should happen.
For validation, Apidog test scenarios chain multiple endpoints into complete workflows. You can build a scenario that registers a user, logs in, creates a resource, and confirms the result, then run it the way a real client would. That end-to-end exercise is how you check the API solves the actual problem, not just that each endpoint matches its line in the spec.
The reporting closes the loop. Apidog generates per-step results, so a failed verification check (a schema mismatch) and a failed validation check (a broken multi-step workflow) are both visible, distinct, and traceable.
Download Apidog to set up both contract-level verification and workflow-level validation against your own API.
A real-world example
Picture a team building a payments API. The spec says POST /payments accepts an amount and a currency, returns 201 with a payment_id, and rejects invalid currencies with a 400.
Verification on this API goes smoothly. Code review confirms the handler matches the design. Schema assertions confirm every response has the documented fields and types. Contract tests confirm the 400 error shape is exactly as specified. Status code checks pass across the board. By every verification measure, the API is built right.
Then the first real client integrates. They discover that the API accepts an amount as a floating-point number, so 0.1 + 0.2 rounds to a value that does not match the customer’s invoice. The spec said “amount: number.” The implementation honored it perfectly. The spec was wrong; money should never be a float. Verification could never have caught this, because verification only checks the implementation against the spec, and both agreed.
Validation catches it. The moment a client runs a real end-to-end payment and reconciles it against an invoice, the rounding error surfaces. The fix is not a code defect report; it is a specification change, amounts become integer minor units. That is the signature of a validation finding: the answer is not “fix the code to match the spec,” it is “the spec itself was wrong.”
This is why both matter. Verification would have shipped a flawless implementation of a broken contract. Validation, exercising the API the way a real consumer does, is the only thing that exposes the contract as the problem.
A practical checklist
For any API release, run both columns:
Verification (against the spec):
- Every endpoint returns documented status codes
- Every response conforms to its schema
- Required parameters are enforced
- Error responses match the documented shape
- Contract tests pass for all consumer-facing endpoints
Validation (against the purpose):
- A new client can complete the core workflow end to end
- The data returned answers real client questions
- The auth flow works for actual integration patterns
- Documented examples match real usage
- Stakeholders confirm the API solves the intended problem
If only the first column passes, you have a correct implementation of a possibly wrong design. If only the second passes, you have the right idea on shaky code. Shipping confidently means both.
Frequently asked questions
Is verification or validation done first? Verification starts first and runs continuously, since you can check code against a spec as soon as code exists. Validation comes once there is a usable product to exercise against real needs.
Is testing the same as validation? No. Testing spans both. Unit tests and schema checks are verification; acceptance and end-to-end tests are validation. The term “testing” covers the whole range.
Can software pass verification but fail validation? Yes, and it is common. The implementation matches the spec perfectly, but the spec solved the wrong problem. That product is verified but not validated.
How does this apply to API contract testing? Contract testing is verification. It confirms an API still honors its documented agreement with consumers. It does not confirm that agreement was the right one; that is validation’s job.
Which one finds more bugs? Verification finds more defects by count, since it runs continuously and catches small deviations early. Validation finds fewer issues but more expensive ones, because a validation failure usually means a requirement or design was wrong, not just the code.
Can automation cover both? Automation handles verification well: schema checks, contract tests, and status assertions run on every commit. Validation is harder to fully automate because it depends on judgment about real-world fit, though end-to-end workflow tests automate a meaningful slice of it.