From a failed call to an approved fix.

Knotbind is a control plane, not an API editor. Your implementation stays in your repository; Knotbind checks it, explains failures and waits for approval.

Demo scenario

In the Demo Sandbox, click Change API contract. The demo makes GET /customers/1 require region=eu. Run Checks twice and Knotbind opens a Finding.

How a repair is drafted

After a Check fails, choose Draft + verify fix. With KNOTBIND_GEMINI_API_KEY set, Knotbind sends Gemini one redacted failure and asks for one request change. The prompt omits credentials. Gemini does not deploy and does not approve.

Knotbind keeps the draft only if the same Check passes in the Sandbox. A declined, unparseable, or failing draft is discarded. The Owner still approves a kept draft before it changes the Check. Without the key, Knotbind uses a local field-extraction heuristic instead.

What happens after you approve

Approval changes Knotbind's Check, not your API and not your repository. The approved request replaces the failing one, the Audit Record names who approved it, and the next scheduled Run calls the new request. When that Run passes, the Finding closes. Nothing is deployed by approving.

GitHub is not required for any of this. Connect a repository only when you want an approved fix written back into your own code. On the Business plan, Deploy approved proposal does one of two things:

• With a deployment webhook configured (KNOTBIND_DEPLOY_WEBHOOK_URL), Knotbind posts the approved change to your pipeline. Your pipeline decides what to do with it.
• With a GitHub repository configured, Knotbind also opens one pull request containing the change. You review and merge it. See Build & handoff.

With neither configured, the button is a dry run and changes nothing. The whole repair loop works without a GitHub account.

Demo versus Customer Sandbox

The Demo Sandbox is a real, deterministic in-process HTTP test server used for demos, onboarding and tests. Its controls change the server behavior for the current Customer: contract drift returns HTTP 422 until region=eu is supplied, outage returns HTTP 503, Restore returns normal responses, and Reset restores the Baseline and reconfigures Checks. It is not a visual-only mockup, but it is intentionally a small simulation rather than a production backend.

For real testing, choose Connected staging API during onboarding. Knotbind runs Checks against the Customer's public HTTPS Sandbox through the guarded Runner, enforcing public destination checks, same-origin paths, GET/POST-only methods, timeouts and response limits. MCP Integrations call the Customer's MCP server through the MCP Invoker instead of the Demo Sandbox. See the complete Sandbox reference.

Check: getCustomer
Request: GET /customers/1
Expected: HTTP 200
Observed: HTTP 422
Reason: field 'region' is required
Proposal: GET /customers/1?region=eu

What an MCP Check looks like

An MCP Check calls a tool rather than an endpoint, so the evidence looks different but the loop is the same. The tool's own declared schemas become the contract, and the shape of the answer becomes the Baseline.

Check: get_customer
Request: MCP tools/call get_customer {"id":"1"}
Expected: HTTP 200, output matches the declared schema
Observed: HTTP 200, 'name' is missing
Reason: response does not match the expected shape
Finding: opened

A tool that changes shape without saying so fails the same way, because the Baseline records what the answer looked like the last time it passed. See MCP servers.

What is persisted