Skip to main content
vet402
Independent MeasurementSeller: purchase results on BaseRead from the database 2026-09-29 10:22 UTC · reused for up to 5 min
vet402Sellers · What to fix firstMethodology

stablepeopledata.dev: x402 purchase results on Base, latest attempt 2026-09-26

2 Base listings. Latest result about the seller at each listing: 0 delivered · 0 failed on the seller's side · 2 with no such result among the attempts shown · 0 not tried yet. This counts, for each listing, the newest purchase that delivered or the newest failure on the seller's side. Attempts on vet402's side, not bought, not sorted, or awaiting on-chain verification are skipped.

By the latest attempt at each listing, whatever it was: 0 delivered · 0 failed on the seller's side · 0 on vet402's side · 2 not sorted (vet402 cannot show the failure was not its own) · 0 not tried yet.

Latest attempt: 2026-09-26 12:02 UTC. This page read the ledger at 2026-09-29 10:22 UTC and reuses that read for up to 5 min.

1.Your listings

  1. stablepeopledata.dev/api/pdl/person/searchPOST
    Latest attempt
    2026-09-26 12:02 UTC
    Result
    Refused, and no payment was taken
    Whose side
    not sorted: no charge
    Decision API now: asking… · the full answer
    What we saw: vet402 signed the payment and the paid request got a 4xx other than 402, with no settlement receipt and no transaction on the row. No money moved, and vet402 cannot rule out that its own request was the problem (held_reason unsettled_4xx), so this page does not count the row as the seller's fault. Since 2026-09-16 23:25 UTC vet402 sends the request body the seller's 402 declares (an empty JSON body when it declares none), and since 2026-09-27 23:27 UTC it adds the query parameters the seller's 402 declares on Base.Last result about the seller: none among the attempts shown. The latest attempt is not sorted; there has been no attempt since.The 402 terms vet402 signed: exact · 0.28 USDC · payTo 0x7f33…0171. Input sent: body declared, query not recorded. The listing's maxTimeoutSeconds is 300; vet402 waits 20 seconds for the paid answer.Signed payment: scheme exact · 0.28 USDC · payTo 0x7f33…0171 · nonce 0xa8f6…21cc · validBefore not recorded.Answer to the paid request: HTTP 400 · Content-Type application/json · no PAYMENT-RESPONSE recorded.What to fix: This page does not count it as the seller's fault. If the request was meant to succeed, declare the input in the listing (body or query) with example values that work as written.Recorded (L1 attempt; vet402 signed a payment, not settled on-chain): settle_failed (vet402 signed a payment and got no settlement receipt back) · HTTP 400 · no tx · held as unsettled_4xx (the paid request got a 4xx with no settlement receipt and no transaction)In export.csv?days=4: the row with attempted_at 2026-09-26T12:02:15Z and resource_key stablepeopledata.dev/api/pdl/person/search.
    After a fixNext purchase by vet402: Not before 2026-10-02 12:02 UTC (a listing is bought at most once every 6 days). After that it depends on the daily budget and the order of demand, so this is the earliest date, not a booking.Email me when this result changesDispute this purchase
    Earlier attempts
    1. 2026-09-11 01:00 UTC · vet402 did not send the declared request body · vet402's sidesettle_failed (vet402 signed a payment and got no settlement receipt back) · HTTP 400 · no tx · held as unsettled_4xx (the paid request got a 4xx with no settlement receipt and no transaction)
      What vet402 recordedBefore 2026-09-16 23:25 UTC, vet402 sent an empty JSON body on paid POST requests, even when the listing declares a body. The seller refused it with 400, 415 or 422, and the payment did not settle (a payment that settled is under "Charged, then refused an input vet402 had not sent").The 402 terms vet402 signed: exact · 0.28 USDC · payTo 0x7f33…0171. Input sent: body not recorded, query not recorded. The listing's maxTimeoutSeconds is 300; vet402 waits 20 seconds for the paid answer.Signed payment: scheme exact · 0.28 USDC · payTo 0x7f33…0171 · nonce 0x0b82…0e60 · validBefore not recorded.Answer to the paid request: HTTP 400 · Content-Type application/json · no PAYMENT-RESPONSE recorded.In export.csv this row's held_reason is unsettled_4xx (the paid request got a 4xx with no settlement receipt and no transaction). This page names the cause the row shows: vet402 did not send the declared request body.
      Dispute this purchase
  2. stablepeopledata.dev/api/pdl/company/enrichPOST
    Latest attempt
    2026-09-23 12:02 UTC
    Result
    Refused, and no payment was taken
    Whose side
    not sorted: no charge
    Decision API now: asking… · the full answer
    What we saw: vet402 signed the payment and the paid request got a 4xx other than 402, with no settlement receipt and no transaction on the row. No money moved, and vet402 cannot rule out that its own request was the problem (held_reason unsettled_4xx), so this page does not count the row as the seller's fault. Since 2026-09-16 23:25 UTC vet402 sends the request body the seller's 402 declares (an empty JSON body when it declares none), and since 2026-09-27 23:27 UTC it adds the query parameters the seller's 402 declares on Base.Last result about the seller: none among the attempts shown. The latest attempt is not sorted; there has been no attempt since.The 402 terms vet402 signed: exact · 0.1 USDC · payTo 0x7f33…0171. Input sent: body declared, query not recorded. The listing's maxTimeoutSeconds is 300; vet402 waits 20 seconds for the paid answer.Signed payment: scheme exact · 0.1 USDC · payTo 0x7f33…0171 · nonce 0x554c…c8ee · validBefore not recorded.Answer to the paid request: HTTP 400 · Content-Type application/json · no PAYMENT-RESPONSE recorded.What to fix: This page does not count it as the seller's fault. If the request was meant to succeed, declare the input in the listing (body or query) with example values that work as written.Recorded (L1 attempt; vet402 signed a payment, not settled on-chain): settle_failed (vet402 signed a payment and got no settlement receipt back) · HTTP 400 · no tx · held as unsettled_4xx (the paid request got a 4xx with no settlement receipt and no transaction)In export.csv?days=7: the row with attempted_at 2026-09-23T12:02:03Z and resource_key stablepeopledata.dev/api/pdl/company/enrich.
    After a fixNext purchase by vet402: Not scheduled: the last 3 paid attempts here did not settle, so the regular sweep does not pick this listing until that changes.Email me when this result changesDispute this purchase
    Earlier attempts
    1. 2026-09-12 06:02 UTC · vet402 did not send the declared request body · vet402's sidesettle_failed (vet402 signed a payment and got no settlement receipt back) · HTTP 400 · no tx · held as unsettled_4xx (the paid request got a 4xx with no settlement receipt and no transaction)
      What vet402 recordedBefore 2026-09-16 23:25 UTC, vet402 sent an empty JSON body on paid POST requests, even when the listing declares a body. The seller refused it with 400, 415 or 422, and the payment did not settle (a payment that settled is under "Charged, then refused an input vet402 had not sent").The 402 terms vet402 signed: exact · 0.1 USDC · payTo 0x7f33…0171. Input sent: body not recorded, query not recorded. The listing's maxTimeoutSeconds is 300; vet402 waits 20 seconds for the paid answer.Signed payment: scheme exact · 0.1 USDC · payTo 0x7f33…0171 · nonce 0xab97…7aac · validBefore not recorded.Answer to the paid request: HTTP 400 · Content-Type application/json · no PAYMENT-RESPONSE recorded.In export.csv this row's held_reason is unsettled_4xx (the paid request got a 4xx with no settlement receipt and no transaction). This page names the cause the row shows: vet402 did not send the declared request body.
      Dispute this purchase
    2. 2026-09-03 01:00 UTC · vet402 did not send the declared request body · vet402's sidesettle_failed (vet402 signed a payment and got no settlement receipt back) · HTTP 400 · no tx · held as unsettled_4xx (the paid request got a 4xx with no settlement receipt and no transaction)
      What vet402 recordedBefore 2026-09-16 23:25 UTC, vet402 sent an empty JSON body on paid POST requests, even when the listing declares a body. The seller refused it with 400, 415 or 422, and the payment did not settle (a payment that settled is under "Charged, then refused an input vet402 had not sent").The 402 terms vet402 signed: exact · 0.1 USDC · payTo 0x7f33…0171. Input sent: body not recorded, query not recorded. The listing's maxTimeoutSeconds is 300; vet402 waits 20 seconds for the paid answer.Signed payment: scheme exact · 0.1 USDC · payTo 0x7f33…0171 · nonce not recorded · validBefore not recorded.Answer to the paid request: HTTP 400 · Content-Type application/json · no PAYMENT-RESPONSE recorded.In export.csv this row's held_reason is unsettled_4xx (the paid request got a 4xx with no settlement receipt and no transaction). This page names the cause the row shows: vet402 did not send the declared request body.
      Dispute this purchase

2.How to read this

Each listing shows its latest attempt on Base and up to four earlier ones. A row where vet402 signed a payment and sent the paid request is an L1 result: “Recorded (L1 paid purchase)” when the payment settled on-chain, and “signed, not settled on-chain” when it did not. A row where vet402 did not sign is marked “not bought” and is not an L1 result. The listing's record page also shows the L0 state (“Published state”), which checks that an unpaid request gets a valid 402, so a listing can pass L0 and still fail here. Whose side puts a failure on the seller's side when the row shows vet402 was not at fault: it signed on the listing's terms, its wallet held the price, it sent the declared input, and the seller answered explicitly or had its declared time. Even then, one such failure is “not sorted: one failure so far”: a failure goes on the seller's side only when the same listing has one on two different days (UTC), and those rows are marked “under re-check” while we re-check them. A row that cannot show all of that is “not sorted”, and so is a held row (held_reason in the export), a failure where no payment was taken (“no charge”), and a payment that settled before the seller refused an input vet402 had not sent. “Signed payment” and “Answer to the paid request” show what the row recorded, and nothing else: the answer's body and header values are not published. The maxTimeoutSeconds on a row is the listing's value today; a declared price or address on a not-bought row is the value recorded at the time of the attempt. The transaction link opens the settlement on Basescan. “Decision API now” is what the decision API (GET /api/v1/resources/{id}/decision?role=payer, no key) answers for the listing when you open this page; your browser asks it for the first 2 listings, and for the others when you ask. Where no money moved, it counts a failure only when this page puts it on the seller's side, and then only toward a WARN. Where money moved, it is cautious for the payer: a paid attempt that took payment and did not deliver counts even when this page leaves it not sorted, and two of them since the last delivery are the only way a failed purchase makes it BLOCK. So it can say WARN or BLOCK for a listing whose failures this page leaves not sorted. The codes that decided the answer come first, each with one sentence on what it means for that listing (reason codes). “After a fix” gives the earliest date vet402's regular sweep can buy the listing again, where the rules let it be worked out, and the links to be told of a change or to dispute a row. Listings removed from the Bazaar, and listings whose catalog network is not Base, are not on this page. The fix-first page groups the same results across sellers (methodology).

3.Think a row is wrong?

Use “Dispute this purchase” on the row: it opens Dispute this record on the listing's record page with the purchase time filled in. Say what you saw instead. The row is not deleted on dispute; a correction is published with the same weight.