Data Validation at the Boundary

The boundary is your defence

Every input from outside — request bodies, query parameters, webhook payloads, third-party responses — is untrusted until proven otherwise. The boundary where that data enters your system is the right place to check it. Validate once, at the edge, and the rest of your code can assume it is working with clean, well-formed data.

Letting unvalidated input flow inward spreads the problem: a malformed field surfaces as a confusing error three layers deep, far from its origin. Catching it at the door turns a mysterious downstream crash into a clear, immediate rejection that names exactly what was wrong.

Validate in layers

Validation has levels, and each catches different mistakes. Structural checks confirm the payload parses and required fields exist. Type and format checks confirm a value is the right shape — a number where a number belongs, a well-formed date, a string within length limits. Business-rule checks confirm the value makes sense in context — an amount that is positive, a status drawn from the allowed set.

if not is_object(body): reject('malformed body')
if not is_email(body.email): reject('invalid email')
if body.amount <= 0: reject('amount must be positive')

Run the cheap structural checks first so obviously broken input fails before you spend effort on it.

Fail fast and clearly

When input is invalid, reject it immediately with an error that explains what was wrong and, where you can, how to fix it. "Field 'amount' must be a positive number" helps the caller; a generic "bad request" or, worse, a 500 from deep inside, does not. Validate as much as you can in one pass and report all the problems together, so callers are not forced to fix one error only to discover the next.

Be strict about what you accept. Silently coercing questionable input often hides bugs that surface later as corrupted data; a clear, early rejection is kinder to everyone.

Normalise on the way in

Validation pairs naturally with normalisation: once input passes, convert it into a single clean internal representation. Trim whitespace, standardise casing where appropriate, parse strings into typed values, and apply consistent units. Your core logic then deals with one tidy shape rather than every variation the outside world sent.

This boundary discipline keeps messy external formats from leaking into your domain, so the same concept is never represented three slightly different ways deeper in the code. Normalising once, at the edge, also means every later comparison, lookup, and calculation operates on predictable values rather than guarding against stray formats of its own. Our developer documentation describes the field formats we expect and return, so you can align your boundary checks with the contract on both sides.