In short
On a warehouse ERP integration we shipped a strict schema validator at the boundary of the middleware: any incoming event missing a required field, with a malformed date, or referencing an unknown SKU was rejected, written to a dead-letter table, and surfaced on a small admin dashboard. We added it for safety - to prevent the integration from getting into a half-finished state. Six months in, the dashboard had become the business's single best source of truth on upstream data quality, catching typos and process drift weeks before they would otherwise have surfaced. This piece is about why that happens, what to put in the dashboard, and why we now treat "dead-letter visibility" as a day-one requirement. The full integration story is in our warehouse ERP case study.
Validate at the boundary, not in the middle
The integration's job was to forward warehouse events to the accounting platform and the CRM. The natural temptation is to validate as you go - check fields when the consuming step needs them, fail at the point of use. We did the opposite. Every incoming event ran through a single JSON schema validator the moment it arrived, before anything else touched it. Anything that did not pass was rejected, with the original payload and the specific validation failure written into a dead-letter row.
This is not a clever pattern. It is just boundary discipline. The result, however, is profound: the rest of the middleware can assume its inputs are valid. There is no defensive code, no scattered "if field is null" checks, no half-processed events. Either the data is good and the pipeline runs cleanly, or the data is bad and it stops at the door with a record of why.
What the dashboard actually shows
The dashboard is unsexy on purpose. One page, three sections:
- Top of the page: a count of dead-letter rows from the last seven days, with a sparkline of the trend. The number you want to see is small and flat. Spikes mean something upstream has changed.
- Middle: a grouping by validation failure type - "missing required field
customer_id," "unknown SKUWGT-…," "malformed date31/02/2026," etc. - with counts. This is what shows you patterns. - Bottom: the raw dead-letter rows themselves, newest first, each with a button to retry (after the upstream issue is fixed) or to mark as resolved-but-do-not-replay.
The warehouse manager opens this page twice a day - once after morning shift handover, once before close. It takes about thirty seconds when nothing is wrong. When something is wrong, the pattern in section two is usually enough to point at the upstream cause without having to dig.
What we have actually caught with it
A sample of real issues from the first nine months, none of which the business would have caught otherwise:
- A new warehouse staff member was being trained on the WMS and entered three test orders with the product code
TEST-001. The integration tried to forward them to accounting, the SKU validator rejected them. The dashboard surfaced the pattern within an hour, the manager intervened, the staff member learned the convention, the test orders never reached the customer-facing systems. - The accounting vendor introduced a new mandatory field in an API update. We did not see the email; the validator did not know about the field. Every outbound write started failing with a known-shape error, the dashboard lit up, we noticed inside a working day and shipped a fix that afternoon. The customer-facing systems never went into a degraded state.
- A long-running data-entry habit - the same operator consistently typing one digit wrong in a particular customer's reference - surfaced as a pattern of "unknown customer reference" rows in the dashboard. The operator did not know they were doing it. We fixed the data, fixed the habit, moved on.
None of those issues are about the integration itself. They are upstream data issues that, before the integration existed, would have been absorbed silently by the rest of the business - and would have surfaced eventually as customer complaints, mis-billed invoices or out-of-stock disputes. The validator made them visible the same day.
Lessons we now apply by default
Ship the dashboard before go-live, not after. Our biggest mistake on that first project was shipping the validator on day one but the dashboard in week eight. For seven weeks we had a growing pile of dead-letter rows that we were checking with a SQL query because the UI was "a nice-to-have." By the time the dashboard existed, the team had developed an instinct to assume the integration was the problem rather than the source data. Putting the dashboard in their hands earlier would have changed that instinct from the start.
Make the failure types human-readable. "Validation error: $.customer_id required" means nothing to a warehouse manager. "Customer id missing from order WMS-1234" means everything. Every validation rule has a paired human-readable failure message; we treat the engineering version as a debug aid and the human version as the actual product.
Treat the dashboard as a business tool, not an ops tool. The most-read page in the integration is the one the warehouse manager opens twice a day. It is not for us; we open it once a week to check it is still working. The dashboard's value is in the hands of the operations team, not the developers.
Related: see how the same boundary discipline plays out in our WooCommerce ↔ Entersoft integration, or our service pages for ERP integration and API integration.