JSON Schema and protobuf schema validation for request and response integrity. Ships Phase 2.

Phase note. Data validation middleware ships Phase 2. The API shown below is the planned interface; it is not available in Phase 1.

Data Validation

CoreSDK validates request and response payloads against JSON Schema (RFC 8259) or protobuf schemas before your handler runs. Validation sits in the middleware pipeline immediately after auth and policy evaluation, so your handler only receives payloads that conform to the declared contract.

Incoming request
      ↓
[1] Auth middleware       — verifies JWT, populates user context
      ↓
[2] Policy middleware     — evaluates Rego policy, short-circuits on deny
      ↓
[3] Validation middleware — checks payload against schema, short-circuits on violation
      ↓
[4] Tracing middleware    — opens OTel span
      ↓
[5] Handler               — receives a guaranteed-valid payload

Schemas are compiled once at startup. There is no per-request parse cost beyond applying the compiled schema to the incoming bytes.

Planned Python API

from coresdk import CoreSDKClient, SDKConfig
from coresdk.validation import ValidationSchema   # Phase 2

_sdk = CoreSDKClient(SDKConfig.from_env())

schema = ValidationSchema.json({
    "type": "object",
    "required": ["user_id", "amount", "currency"],
    "properties": {
        "user_id":  {"type": "string", "format": "uuid"},
        "amount":   {"type": "number", "minimum": 0.01},
        "currency": {"type": "string", "enum": ["USD", "EUR", "GBP"]},
        "note":     {"type": "string", "maxLength": 280},
    },
    "additionalProperties": False,
})

Planned Rust API

The coresdk_engine crate will expose a ValidationSchema type and Tower layer:

use coresdk_engine::{Engine, EngineConfig};
use coresdk_engine::validation::ValidationSchema;  // Phase 2

let schema = ValidationSchema::json(serde_json::json!({
    "type": "object",
    "required": ["user_id", "amount"],
    "properties": {
        "user_id": { "type": "string" },
        "amount":  { "type": "number", "minimum": 0 },
    }
}))?;

Validation error format

When a payload violates the schema, CoreSDK returns HTTP 422 Unprocessable Entity following RFC 9457:

{
  "type": "https://errors.coresdk.io/validation/schema-violation",
  "title": "Request payload failed schema validation",
  "status": 422,
  "detail": "2 validation errors in request body",
  "trace_id": "01HX7KQMB4NWE9P6T2JS0RY3ZV",
  "errors": [
    {
      "field": "/amount",
      "message": "must be >= 0.01",
      "schema_path": "#/properties/amount/minimum"
    },
    {
      "field": "/currency",
      "message": "must be one of: USD, EUR, GBP",
      "schema_path": "#/properties/currency/enum"
    }
  ]
}

All violations are reported in a single pass — CoreSDK does not stop at the first error.

Using validation results in Rego policies (planned)

Validation results will be available in the Rego policy input under input.validation:

package coresdk.authz

default allow = false

allow {
    input.validation.passed
    input.user.role == "payments:write"
}

Validation modes (planned)

Mode	Behavior
`enforce` (default)	Failure short-circuits the pipeline, returns 422
`observe`	Results recorded in `input.validation`, request not rejected
`disabled`	Validation middleware removed from the chain

Next steps

Middleware Pipeline — where validation sits in the full request chain
Error Handling — how to customize RFC 9457 error responses
Authorization with Rego — writing policies that combine user context and validation results

Data Validation

Data Validation

Planned Python API

Planned Rust API

Validation error format

Using validation results in Rego policies (planned)

Validation modes (planned)

Next steps

On this page