Developer Data Validation Guide

A practical validation workflow for API payloads, configuration files, imports and integration data. Last updated August 27, 2026.

Data validation is not one feature. It is a chain of small decisions that starts when a user or system creates data and ends when another service trusts that data. A formatter can make payloads readable, a linter can catch style or structure problems, a parser can decide whether a document is valid syntax and a schema can describe the contract a system expects. Production validation usually needs more than one of those layers.

Formalint focuses on browser-based tools and reference notes for the early part of that workflow: cleaning examples, inspecting payloads, checking common shapes and preparing safe samples for debugging. This guide explains where those tools fit and where application code, backend checks and integration tests still matter.

Start With the Boundary

Before writing validation rules, name the boundary you are protecting. A signup form, an internal admin screen, a webhook endpoint, a CSV import, a partner API and a configuration file all fail in different ways. Client-side validation improves feedback for the person entering data, but it cannot be the only authority. Server-side validation protects the application. Integration validation protects contracts between teams and vendors.

For API work, the most important question is not "is this valid JSON?" but "is this valid for this endpoint at this moment?" A payload can be syntactically valid and still fail because a required field is missing, a value has the wrong domain meaning, an enum changed, a timestamp is outside the allowed window or a nested object belongs to another version of the contract.

Separate Syntax From Meaning

Syntax validation answers whether the document can be parsed. JSON must use double-quoted property names and cannot contain trailing commas. XML must be well-formed, with one root element and correctly nested tags. YAML depends heavily on indentation, block style and scalar interpretation. These are format-level checks. They help you get to the next step, but they do not prove business correctness.

Meaning validation answers whether parsed data satisfies the rule your system actually cares about. A string may be valid JSON and still not be a valid email address for your product. A date string may match a regex and still represent an impossible calendar date. A status field may be present and still use a value your workflow no longer accepts. Keep these layers separate so errors are easier to explain.

Use Schemas Where Contracts Matter

Schemas are useful when multiple systems need a shared contract. JSON Schema can describe required fields, primitive types, arrays, nested objects, enums and simple string constraints. XML Schema can define element structure and attribute expectations. OpenAPI can document endpoint contracts and expected responses. A generated schema is a draft, not a replacement for review, but it can quickly expose inconsistent examples.

Use the JSON Schema Generator to create a first pass from sample JSON, then review every required field, nullable value and array item. A generator cannot know whether an optional field happened to be missing from the sample or whether a string should be limited to a specific enum. That decision belongs to the team that owns the contract.

Validate Close to the Source

The earlier you reject bad data, the cheaper the fix usually is. A browser form can prevent a user from submitting a clearly malformed value. A backend endpoint can reject unauthorized or out-of-range input before it reaches storage. A background import job can quarantine rows with missing identifiers. A webhook receiver can log and return a clear error when a partner sends an unexpected shape.

That does not mean every layer repeats every rule. Put fast feedback in the client, authoritative rules on the server and contract tests around integrations. If a rule controls money, permissions, inventory, personal data or irreversible workflow state, the server should enforce it even when the client already checked it.

Regex Is a Shape Check

Regex is useful for simple string shape checks: UUIDs, slugs, phone-like strings, date-like strings and coarse email checks. It is less useful for complex grammars, nested documents or business rules. A regex can say a value looks like a date; a date parser should decide whether the date exists. A regex can require an HTTPS-looking URL; a URL parser should interpret the host, path, query and port.

If a regex becomes a wall of lookarounds, alternatives and nested quantifiers, split the rule into readable checks. Use the Complete Regex Guide and Regex Tester to test valid, invalid, empty, long and edge-case values before copying a pattern into production.

Check Error Messages Like Product Behavior

Validation is part of the user experience. "Invalid payload" may be enough for a log line, but it is not enough for a person trying to fix a form or a partner trying to repair an integration. Good validation errors name the field, explain the rule and avoid leaking sensitive details. They should also be stable enough for support teams and integration partners to search internal notes.

For public APIs, prefer errors that include a machine-readable code, a human-readable message and a pointer to the field when possible. For imports, keep rejected rows with reasons so the data owner can repair the source file. For internal tools, show the rule near the field so the user does not need to guess.

Protect Sensitive Samples

Developers often use real payloads while debugging. Before pasting data into any web tool, remove secrets, access tokens, customer names, emails, phone numbers, addresses, payment details and internal identifiers. Formalint's current static tools process input in the browser, but safe sample discipline still matters. A copied payload can be shared in chat, screenshots, bug reports or browser history after the tool has done its job.

Use realistic fake values. Preserve structure, lengths and edge cases, but replace private data. If a bug depends on a secret value, reproduce it in a controlled environment rather than pasting production material into a generic tool.

A Repeatable Validation Checklist

Confirm the input boundary: browser, API, import job, webhook, config file or internal tool.
Validate syntax first with the correct parser for JSON, XML, YAML or CSV.
Validate schema and required fields before checking deeper business rules.
Use regex only for narrow string shapes and test both passing and failing examples.
Keep server-side checks for any rule that affects security, billing, permissions or persisted state.
Log enough context to debug the failure without storing secrets or private data unnecessarily.
Document common failures so future developers do not rediscover the same rules during incidents.

Where Formalint Fits

Use Formalint to clean JSON, compare payloads, lint XML, review YAML indentation, test regex patterns, inspect HTTP status codes and prepare readable snippets for tickets. Then move the final rule into your application code, API contract, test suite or import pipeline. The goal is not to replace engineering judgment; it is to make the messy input clear enough that judgment can work.