When a CRM, accounting system, support tool, or custom application exchanges data with another system, the handoff is a risk point. A field that is missing, renamed, formatted differently, or interpreted incorrectly can create duplicate records, failed jobs, confusing reports, or manual cleanup.
The practical answer is to validate data at the boundary where it enters a system. The receiving system should not assume that a value is correct because another system produced it. Validation is not about rejecting every imperfect request. It is about making the accepted shape explicit, catching problems close to their source, and giving people enough information to fix them.
Start with the business meaning of each field
Before writing a schema or regular expression, describe what each field means to the business. “Customer status” might be a small set of workflow states, while “notes” may be intentionally free-form. “Invoice date” may need a date and time zone, while “contact name” should not be limited to an overly narrow character set.
For each field, document five decisions:
- Is the field required, optional, or conditionally required?
- What data type and format does the receiving system accept?
- What values are allowed, and which values are explicitly disallowed?
- What is the maximum size or practical range?
- Who owns the rule when the business process changes?
This small field inventory becomes a usable contract between the systems. It also prevents a common mistake: treating validation as a purely technical task when the most important question is what a value means in the workflow.
Normalize carefully, then validate
Systems often represent the same value in slightly different ways. One may include leading or trailing spaces, use a different case, send an empty string instead of a missing value, or format a phone number with punctuation. Decide which transformations are safe before comparison. Trimming whitespace may be reasonable; silently changing a customer name or guessing a time zone may not be.
Normalization should be predictable and observable. Keep the original value when an audit trail or later review requires it, and record which transformation was applied. Do not use a “clean everything” rule that removes characters people legitimately need. OWASP’s input validation guidance recommends allowlisting authorized values and using normalization for canonical encoding, while also noting that validation alone is not a complete defense against every security issue.
After normalization, validate against the receiving system’s actual contract. Reject unknown enum values rather than mapping them to a convenient default unless the business has explicitly approved that behavior. A default can keep a job moving while quietly putting a record in the wrong workflow.
Return errors that a person can act on
An HTTP 400 response tells a caller that the request was not accepted, but it does not tell an operations person what to do next. A useful validation error identifies the field, the problem, and the request or record that needs attention. For example, “status must be one of pending, approved, or cancelled” is more useful than “invalid payload.”
For APIs, use a consistent error shape across endpoints. RFC 9457 defines a standard problem-details format for carrying machine-readable error information in HTTP responses. A practical implementation can include a stable problem type, a human-readable detail, a correlation identifier, and field-level errors. Keep sensitive values out of the response and logs; show enough context to fix the data without echoing private information.
Separate errors that can be corrected from errors that should be retried. A missing required field needs a data correction or code change. A temporary service outage may need a bounded retry. Treating both as the same failure creates either noisy retries or avoidable manual work.
Choose a safe behavior for each failure
There is no single correct response to invalid data. For a customer update, rejecting the whole request may be safest. For a batch import, isolating the invalid record and processing the valid records may be more useful, provided the outcome is clearly reported. For a financial or inventory change, a partial success may require stronger controls and reconciliation.
Write the decision into the integration design. Define whether the operation is all-or-nothing, how duplicates are detected, where rejected records go, and who is notified. Include an idempotency strategy for operations that may be retried so a timeout does not create the same business action twice. These choices are part of the workflow, not implementation details to leave to chance.
Test the boundary with realistic cases
A happy-path sample proves very little. Build a small test set with missing fields, extra fields, wrong types, unexpected enum values, long text, duplicate identifiers, different time zones, non-ASCII names, stale records, and malformed nested objects. Add cases that are valid but unusual, because overly strict validation can be just as disruptive as weak validation.
Test both sides of the boundary. The sender should produce the documented contract, and the receiver should reject or quarantine data it cannot safely interpret. Contract tests can catch a renamed field before a release reaches production. They should be paired with a few end-to-end tests that confirm the actual business result, not just the shape of the JSON.
Give the rule an owner and a feedback loop
Validation rules become obsolete when a workflow changes. Assign an owner for the contract and review rejected-record reports regularly. Track practical signals such as rejection reasons, repeated fields in error, time to correction, duplicate frequency, and manual reconciliation work. These are operational clues, not promises of a particular performance level.
When a rule changes, document whether the change is backward-compatible, update the examples, and communicate the new expectation to the team responsible for the other system. For public or long-lived APIs, consider versioning rather than changing a meaning in place. For internal integrations, a short migration window and a clear deprecation date may be enough.
A workable first implementation
- Choose one high-friction handoff, such as a CRM-to-accounting or form-to-operations workflow.
- List the fields, business meanings, allowed values, owners, and failure behavior.
- Normalize only the values the business has agreed can be transformed safely.
- Return consistent, field-level errors with a correlation identifier and no sensitive data.
- Test normal, unusual, malformed, duplicate, and stale inputs before expanding the integration.
- Monitor rejection reasons and review the contract when the process changes.
Good boundary validation makes integrations easier to operate because problems appear where they can be understood. It gives developers a precise contract, gives operations teams actionable failures, and gives business owners a place to review changing rules. Start with one important handoff and make its assumptions visible before adding more automation.
Next step: Schedule a short consultation to identify the next useful improvement.