Guard API

Stop bad data before it reaches your application. Guard sits in front of your ingestion pipeline — forms, webhooks, API imports, CRM syncs — validates each record against your schema, repairs the safe issues, and returns a clear per-record decision: pass, repair, review, or reject, each with reasons and confidence.

Endpoint & cost

POST /api/v1/guard

Metering is based on input records: 100 records sent to Guard draws down 100 records. The synchronous maximum is 500 records per request. Requests that fail validation are never charged.

The four decisions

• pass — the record is already valid; no changes needed.
• repair — safe issues were fixed automatically; data holds the repaired record and changes the audit trail.
• review — something is off but not fatal; a human should look. data is still returned.
• reject — a required field is invalid and cannot be safely repaired; data is null and issues explains why.

Per-record pipeline

• Check required fields are present.
• Validate each value against its declared type.
• Normalize and safely repair values that can be fixed with confidence.
• Optionally flag likely duplicates and anomalies across the batch.
• Apply your policy and return the decision, repaired data, reasons, and confidence.

Request fields

Response

Policy

Policy controls the balance between automation and safety. The defaults repair safe issues and reject records whose required fields cannot be fixed. Set reject_invalid_required_fields: false to route those to review instead of rejecting them, or reject_low_confidence_repairs: true to refuse anything that would need a low-confidence fix. Turn on detect_duplicates or detect_anomalies to add cross-record review signals.

Errors & limits

• 400 invalid_request — empty records, a nested/non-primitive value, or an empty schema.
• 400 invalid_request — a schema field declares an unknown type.
• 413 payload_too_large — the body exceeds the size cap or more than 500 records.
• 401 unauthorized / invalid_api_key — missing or invalid key.
• 429 usage_limit_exceeded / rate_limit_exceeded — allowance or burst limit reached.

A record-level reject is a normal 200 result, not an HTTP error. Internal errors return a sanitized 500 internal_error and never leak record contents. See Errors.

Try it live

Pick a scenario or edit the JSON, then send it against the live engine. No API key required.

Example request

POST /api/v1/guard
Authorization: Bearer zap_live_...
Content-Type: application/json

{
  "records": [
    { "email": " JOHN@ACME.COM ", "company": "Acme Inc", "revenue": "$1.2M" },
    { "email": "not-an-email", "company": "", "revenue": "1200000" },
    { "email": "jane@globex.com", "company": "Globex", "revenue": "450000" }
  ],
  "schema": {
    "email": { "type": "email", "required": true },
    "company": { "type": "string", "required": true },
    "revenue": { "type": "number" }
  },
  "policy": { "repair_safe_issues": true, "reject_invalid_required_fields": true }
}

Example response

{
  "request_id": "req_xxx",
  "success": true,
  "results": [
    {
      "record_index": 0,
      "decision": "repair",
      "confidence": 0.98,
      "issues_found": 0,
      "repairs_applied": 2,
      "data": { "email": "john@acme.com", "company": "Acme Inc", "revenue": 1200000 },
      "changes": [
        { "field": "email", "from": " JOHN@ACME.COM ", "to": "john@acme.com", "reason": "email trimmed and lowercased", "confidence": 0.99 },
        { "field": "revenue", "from": "$1.2M", "to": 1200000, "reason": "currency value parsed to a numeric amount", "confidence": 0.97 }
      ],
      "issues": []
    },
    {
      "record_index": 1,
      "decision": "reject",
      "confidence": 1,
      "issues_found": 2,
      "repairs_applied": 0,
      "data": null,
      "changes": [],
      "issues": [
        { "field": "email", "issue": "invalid_email", "reason": "\"not-an-email\" is not a valid email for \"email\" and cannot be safely repaired." },
        { "field": "company", "issue": "missing_required_field", "reason": "Required field \"company\" is missing or empty." }
      ]
    },
    {
      "record_index": 2,
      "decision": "pass",
      "confidence": 1,
      "issues_found": 0,
      "repairs_applied": 0,
      "data": { "email": "jane@globex.com", "company": "Globex", "revenue": "450000" },
      "changes": [],
      "issues": []
    }
  ],
  "summary": { "records_received": 3, "passed": 1, "repaired": 1, "review": 0, "rejected": 1 },
  "usage": { "records_processed": 3, "credits_used": 3, "credits_remaining": 997 }
}

Code examples

curl -X POST https://zapinner.com/api/v1/guard \
  -H "Authorization: Bearer $ZAPINNER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "records": [
      { "email": " JOHN@ACME.COM ", "company": "Acme Inc", "revenue": "$1.2M" }
    ],
    "schema": {
      "email": { "type": "email", "required": true },
      "company": { "type": "string", "required": true },
      "revenue": { "type": "number" }
    },
    "policy": { "repair_safe_issues": true, "reject_invalid_required_fields": true }
  }'

Related

• Repair — the repair engine Guard uses to fix safe issues.
• Map — reshape data into your target schema.
• Anomalies — the anomaly-detection engine Guard can enable.