// Validation
Validate data before it enters another system.
Check structure, formats, and contact data — and reject what doesn't meet your rules — before it reaches the next system.
Who this is for
- Developers putting a validation boundary in front of a database or CRM
- Platform teams enforcing a data contract on inbound webhooks and uploads
- Data teams who want malformed records rejected, not silently stored
The problem
Bad data is cheapest to stop at the door. Once malformed records land in a CRM, warehouse, or downstream app, the cleanup is far more expensive than the check would have been.
Where it goes wrong
Malformed inbound webhooks
A partner starts sending a field in a new shape. Without validation at the boundary, the bad shape propagates into every downstream table before anyone notices.
Uploads that poison a table
A single CSV with a mis-typed column corrupts a load. Validating structure and formats up front turns a silent data incident into a clear, per-row rejection.
How it works
Send records to Guard
Pass incoming records to the Guard endpoint before they're written anywhere.
Validate against your rules
Structure, field formats, and contact data are validated deterministically, with clear pass/fail results per record.
Reject or flag what fails
Records that don't meet your expectations are rejected or flagged with the specific reason, so only clean data moves forward.
How Zapinner solves it
Deterministic pass/fail
Guard checks structure, field formats, and contact data against the expectations you declare and returns a clear pass/fail per record with the specific reason for any failure — the same input always yields the same verdict.
Reject or route
Failing records can be rejected outright or flagged for a downstream path, so you decide whether bad data stops at the door or goes to a review queue.
Guard records at the boundary
curl -X POST https://zapinner.com/api/v1/guard \
-H "Authorization: Bearer $ZAPINNER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"records": [
{ "email": "not-an-email", "phone": "+17045551234" }
],
"expect": { "email": "email", "phone": "phone" }
}'
# -> { passed: false, failures: [{ field: "email", reason: "invalid_format" }] }Reliability & security
Explainable rejections
Every failure comes with the field and a specific reason, so a rejected record is actionable rather than a mystery.
The outcome
Clean data at the boundary, fewer downstream incidents, and a clear, per-field record of what failed and why.
Frequently asked
- How is Guard different from just cleaning the data?
- Cleaning changes values; Guard decides whether a record is allowed through. Use Guard to enforce a contract at the boundary and Repair to fix records you've chosen to accept.
- Can I validate nested or structured payloads?
- Guard validates the fields and formats you declare in your expectations. For richer reshaping of nested payloads, pair it with the Map/transform endpoints.