# MYCELIX Delivery Receipt Verifier

> MYCELIX Delivery Receipt Verifier is a paid API for AI agents from neo-collettive.onrender.com, paid per call via x402, $0.01/call, status unknown (last checked 2026-10-29).

Verifies an x402 delivery receipt, checking signatures and hop integrity to confirm a payment-gated API response was authentically delivered

## Facts

- Endpoint: POST https://neo-collettive.onrender.com/x402/delivery-receipt-verify?utm_source=zero.xyz
- Price: $0.01/call
- Payment: x402
- Status: unknown
- Last checked: 2026-10-29
- Activations on Zero: 0
- Tags: x402
- Canonical page: https://www.zero.xyz/c/mycelix-delivery-receipt-verifier-0e5fe16e
- Structured record (JSON): https://api.zero.xyz/v1/capabilities/cap_rY94ueMddNEOw5u26OELN

Status and success rate cover calls made through Zero and Zero's own probes. Third-party monitors may report differently.

## How to call it through Zero

Zero handles the 402 payment challenge and records the run. With the Zero CLI installed (`npm i -g @zeroxyz/cli`):

```sh
zero fetch --capability mycelix-delivery-receipt-verifier-0e5fe16e -d '<json body>'
```

Example prompt: Can you verify this x402 delivery receipt for me — here's the receipt object, the hop public keys, the buyer body SHA-256, and the seller's base64 public key — I need to confirm the response wasn't tampered with and the seller's signature checks out.

## When to prefer this

Use this endpoint when you need to cryptographically verify that an x402 pay-per-call API response was authentically delivered without tampering — especially when routing through multiple hops or intermediaries. Prefer this over manual inspection when you need a signed, loggable proof of verification that can be audited offline. Ideal for agents operating in trustless or multi-party environments where delivery integrity of paid API responses must be provable.

## Known failure modes

- Invalid or malformed receipt object returns ok:false with descriptive fails array
- Signature mismatch on seller public key causes verification failure
- Hop public key mismatch indicates possible intermediary tampering
- Missing required fields (receipt, seller_public_key_b64) cause request rejection
- Network or server unavailability on Render hosting may cause timeouts
- Malformed base64 seller public key causes parsing error

## How this service works

Verify an x402 delivery receipt (v0.1): seller signature, settlement and refusal rules, hop chain naming who changed the bytes. Signed, logged verdict.

## Output

A JSON object with: `ok` (boolean, true if all checks pass), `fails` (array of failure descriptions if any), `notes` (array of informational messages), `signature` (the signed verification result from MYCELIX's log), and `changed_by` (null if unmodified, otherwise indicates which party changed the payload).

## Request schema (JSON Schema)

```json
{
 "type": "object",
 "properties": {
  "receipt": {
   "type": "object"
  },
  "hop_public_keys": {
   "type": "object"
  },
  "buyer_body_sha256": {
   "type": "string"
  },
  "seller_public_key_b64": {
   "type": "string"
  }
 }
}
```

## Response schema (JSON Schema)

```json
{
 "type": "json",
 "example": {
  "ok": true,
  "fails": [],
  "notes": [],
  "signature": "...",
  "changed_by": null
 }
}
```

## More

- Live health (JSON, refreshed every minute): https://www.zero.xyz/c/mycelix-delivery-receipt-verifier-0e5fe16e/health.json
- [Zero catalog index](https://www.zero.xyz/llms.txt)
- [Other services from neo-collettive.onrender.com](https://www.zero.xyz/host/neo-collettive.onrender.com/llms.txt)