Ontario Protocol.
Listing remediation

Fix a Pending x402 Listing (Pending → Ready)

If your service shows up as pending or needs_work, Ontario will keep it out of /discover by default. This is intentional: agents should not pay based on marketing copy. Use this loop to get to grade=ready with a fresh public report.

Commands

1) Run the free verifier (stores a public report) 
curl -X POST https://ontarioprotocol.com/api/verify/x402-readiness \
  -H "Content-Type: application/json" \
  -d '{"target_url":"https://example.com/api/paid-endpoint"}'
2) Probe your paid endpoint (expect HTTP 402 before payment) 
curl -i https://example.com/api/paid-endpoint
3) Submit a listing only after grade=ready (paid x402 call) 
curl -i -X POST https://ontarioprotocol.com/api/x402/list-service \
  -H "Content-Type: application/json" \
  -d '{"name":"Example Service","description":"Paid endpoint","endpoint":"https://example.com/api/paid","method":"POST","price_usdc":"0.01","network":"base","owner_url":"https://example.com"}'

Understand the pipeline (pending vs discoverable)

Ontario treats listing and discovery as separate states. /listings can include pending entries so builders can iterate in public. /discover is a strict, agent-facing catalog and is filtered to endpoints with strong readiness evidence.

Evidence: The /discover UI states it is a machine catalog with strict filters (grade, score, verification history). /listings explains that third-party endpoints enter /discover only when verified/ready.

Fix: Use /listings as your staging area; use /verify to reach grade=ready; then expect /discover inclusion once a fresh stored report is ready.

Make the unpaid request fail closed with a usable HTTP 402 challenge

Agents need a machine-readable payment requirement before retrying. A bare 402 without decodable metadata forces agents to guess, and Ontario flags it as a readiness failure.

Evidence: Ontario’s verifier explicitly checks 402 payment challenge behavior and shows a red signal when challenge metadata is missing or inconsistent.

Fix: Verify the 402 response contains x402-compatible requirements (scheme/network/asset/amount/resource/expiry) and that the gated resource matches the endpoint you submitted.

Keep /.well-known/x402.json consistent with the live challenge

Agents reconcile your manifest against the observed challenge. Network/asset/price/method drift is one of the fastest ways to get denied by policy even if you technically return a 402.

Evidence: Ontario checks for /.well-known/x402.json and compares manifest fields against observed behavior; mismatches reduce score and can block discovery promotion.

Fix: Treat the manifest as a contract: update it when pricing/network/method changes, include stable owner_url/service URLs, and keep generated_at fresh.

Publish OpenAPI for the paid endpoint (reduce agent execution risk)

Paid endpoints without schemas are hard to safely call. Agents cannot validate request inputs, constrain outputs, or estimate downstream spend, so Ontario penalizes missing OpenAPI evidence.

Evidence: Ontario readiness includes an OpenAPI signal and links schema evidence from reports/service profiles when present.

Fix: Expose an OpenAPI document that includes the paid path, method, request body schema, and response schema; ensure it matches the endpoint in your manifest and listing submission.

Make the report linkable evidence (don’t rely on badges alone)

A badge is a pointer, not proof. Agents should cite the public report ID (and integrity endpoint) as their pre-payment receipt.

Evidence: Ontario readiness reports are public and signed; report pages include score, warnings, history, and integrity checks.

Fix: Add the public report URL to your docs and listings page, and embed the badge SVG only as a secondary affordance.

Sources

Run the verifier