A smooth JSON‑schema pipeline that enforces human-in-the-loop approval, only lets approved changes pass, while every request is logged and can be reviewed, is the ideal state for teams that need human oversight.
In practice, many organizations push schema files straight from a developer’s workstation into version control, let continuous‑integration pipelines apply them to production services, and assume that code review or automated linting is enough. The reality is far messier. A typo in a required field, an accidental removal of a property, or a subtle change to a numeric constraint can break downstream data pipelines, cause runtime validation failures, and force hot‑fixes that ripple through multiple services. Because the change travels directly from the source repository to the validation endpoint, there is no point where a human can say “stop, this needs a second pair of eyes.” Moreover, the operation is rarely recorded in a way that satisfies auditors or post‑mortem analysis.
Why human-in-the-loop approval alone isn’t enough
Introducing a policy that “every schema change must be approved by a senior engineer” sounds like progress, but the approval step often lives in a separate tool, pull‑request reviews, ticketing systems, or manual email threads. The actual request to apply the schema still reaches the target service directly, bypassing any enforcement. The result is a gap: the request is authorized on paper but not technically gated, so a rogue script or a mis‑configured CI job can still push the change. Without a data‑path control, you cannot guarantee that the approved version is the one that gets applied, nor can you capture a reliable audit trail of who invoked the change and what the payload contained.
What you need is a single control surface that sits between the identity that initiates the request and the JSON‑schema validation service. That surface must be able to enforce the approval workflow, record the transaction, and optionally mask any sensitive metadata before it reaches the downstream system.
hoop.dev as the data‑path enforcement point
hoop.dev provides exactly that. It acts as an identity‑aware proxy for any HTTP‑based JSON‑schema endpoint. The gateway is deployed inside the same network segment as the validation service, and every client, whether a CI job, a developer’s CLI, or an automated script, connects through hoop.dev instead of reaching the service directly.
- Setup: Identity is handled via OIDC or SAML. Teams configure the gateway to trust tokens from their IdP, map groups to permission sets, and grant the minimal role needed to request a schema change. This step decides who can start a request but does not enforce the policy itself.
- The data path: All traffic to the schema service passes through hoop.dev. Because the gateway terminates the protocol, it can inspect the JSON payload before it is forwarded.
- Enforcement outcomes: hoop.dev checks whether the request has an associated human‑in‑the‑loop approval. If approval is missing, it blocks the call and returns a clear error. When approval exists, hoop.dev records the full request and response, stores the audit entry, and can mask fields such as API keys that appear in the schema definition. The recorded session can be replayed later for forensic analysis.
Because hoop.dev is the only component that can see the request in clear text, the enforcement outcomes exist solely because the gateway is in the data path. Removing hoop.dev would revert the system to the insecure state described earlier.
How the workflow looks in practice
- A developer creates a pull request that updates a JSON schema file.
- The CI pipeline extracts the change and attempts to POST it to the validation endpoint.
- The request is intercepted by hoop.dev. The gateway reads the caller’s OIDC token, verifies group membership, and looks for an approval record attached to the change.
- If the approval is present, hoop.dev forwards the request, masks any fields you have marked as sensitive, and logs the full exchange. If not, hoop.dev rejects the request and notifies the approver.
- Auditors can later query the hoop.dev audit store to see who approved, when the request was made, and what the exact JSON payload was.
This pattern eliminates the gap between policy and enforcement. The human‑in‑the‑loop step is enforced at the network level, not just in a ticketing system.
Getting started
To try this approach, follow the getting‑started guide to deploy the gateway in a Docker Compose environment. The guide walks you through configuring OIDC, defining a JSON‑schema connection, and enabling approval workflows. For deeper details on masking, session recording, and audit queries, see the feature documentation. Both resources assume you have an existing IdP and a validation service that accepts HTTP POSTs.
FAQ
Do I need to change my existing CI pipelines?
No. The only change is the endpoint URL. Pipelines continue to POST JSON, but the target address now points to hoop.dev, which forwards the request after applying the policy.
Can I use hoop.dev with multiple schema services?
Yes. Each service is registered as a separate connection in the gateway, and you can assign different approval groups per connection.
What happens if an approval is revoked after a request is recorded?
hoop.dev records the state of the approval at the moment the request is processed. Revoking later does not alter the already‑logged session, preserving an immutable audit trail.
Explore the open‑source repository on GitHub to contribute, raise issues, or customize the gateway for your environment.
