How can you generate compliance evidence for every JSON schema validation you run, ensuring the process is auditable and tamper‑free?
Most teams treat schema checks as a build‑time convenience. A developer runs a local validator, a CI job invokes the same library, and the result is a pass/fail flag. The logs live in the CI system, the build server, or a developer’s terminal. When an auditor asks for proof that a particular payload conformed to a schema on a specific date, the organization must piece together fragmented logs, often discovering gaps, missing timestamps, or redacted fields. The current state provides no immutable trail, no ability to mask personally identifiable information, and no central point where approval can be required before a risky payload is accepted.
What we really need is continuous compliance evidence that records every validation request, who made it, and the exact response, while still allowing the validation to happen where the data lives. The requirement fixes the visibility problem, but the request still travels directly to the validator process. Without an intervening gateway, the system fails to enforce masking, fails to trigger a just‑in‑time approval workflow, and cannot keep the audit record safe from alteration by the validating process.
For an overview of what hoop.dev offers, see the product page.
Why continuous compliance evidence matters for JSON schema
Regulatory frameworks such as SOC 2 or industry‑specific data‑handling rules often demand proof that data validation is performed consistently and that any sensitive fields are protected during that process. Continuous compliance evidence satisfies three audit pillars:
- Completeness: hoop.dev captures every validation request, not just the ones that succeed.
- Integrity: hoop.dev stores the record outside the validating process, preventing post‑hoc tampering.
- Confidentiality: hoop.dev masks fields like social security numbers before they appear in logs.
Achieving these pillars requires a boundary that sits between the caller and the validator. That boundary must be identity‑aware, enforce policies in real time, and produce immutable audit trails.
hoop.dev as the data‑path enforcement point
hoop.dev is a Layer 7 gateway that proxies connections to infrastructure components, including HTTP‑based services that expose JSON schema validation APIs. The architecture follows a three‑step model:
- Setup: Users authenticate with an OIDC or SAML provider. The identity token tells hoop.dev who is requesting validation and what groups they belong to.
- The data path: The validation request routes through hoop.dev instead of directly to the validator. Because hoop.dev sits in the data path, it is the only place where enforcement can occur.
- Enforcement outcomes: hoop.dev records each request and response, masks any fields marked as sensitive, and can pause the request for a human approver if the payload exceeds a risk threshold.
Because hoop.dev holds the credential used to call the validation service, the caller never sees the secret. hoop.dev records each session, providing a replay‑able log that auditors can query without needing access to the underlying validator host.
How hoop.dev generates audit‑ready compliance evidence
When a JSON payload arrives, hoop.dev extracts the identity from the OIDC token, checks the request against policy rules, and forwards it to the validator. hoop.dev applies any configured masking patterns, then records the masked request and the corresponding response in its immutable audit log. The resulting entry includes:
- Timestamp in UTC
- User or service account identifier
- Operation name (validate‑json‑schema)
- Masked payload
- Validation outcome (pass/fail, error details)
These fields satisfy typical auditor checklists for compliance evidence. Because hoop.dev creates the log at the moment of validation, the organization can prove that the record was generated independently of the validator’s own logging.
Inline masking protects sensitive data
Regulators often require that personally identifiable information never be stored in clear text. hoop.dev replaces a credit‑card number with a token before it reaches the audit store, while the validator still receives the original value. This approach keeps functional correctness while ensuring the compliance record contains only masked data.
Just‑in‑time approvals reduce risk
Some schemas include conditional rules that, if violated, indicate a high‑risk transaction. hoop.dev triggers a workflow that pauses the request and routes it to an authorized reviewer. hoop.dev captures the approval decision alongside the validation log, giving auditors a complete picture of why a risky payload was allowed or rejected.
Getting started with hoop.dev for JSON schema validation
To adopt this model, begin with the getting‑started guide. Deploy the gateway using the provided Docker Compose file, register your JSON‑validation endpoint as a connection, and define masking and approval policies in the UI. The open‑source repository on GitHub contains the full source code and example configurations: Explore the open‑source repository on GitHub. Once the gateway is in place, all validation traffic will flow through hoop.dev, automatically generating the continuous compliance evidence your auditors expect.
FAQ
Do I need to change my existing validation code?
No. hoop.dev works at the protocol layer, so your existing client libraries continue to send requests to the same endpoint URL. The only change is that the URL now points to the hoop.dev gateway instead of the validator directly.
Can hoop.dev mask fields that are not part of the JSON schema?
Yes. Masking rules are defined independently of the schema, allowing you to protect any sensitive attribute that may appear in the payload.
What happens if the gateway is unavailable?
Because hoop.dev is the only path that enforces policy, a temporary outage will block validation requests. This is intentional: it prevents ungoverned access. You can configure high‑availability deployments to meet your availability requirements.
