verb_not_found

HTTP 404   title: No such verb

What it means

No verb by that NAME is registered at this operator. The last segment of the path you dialed matches nothing in this origin’s catalogue — a typo, a name you remembered from a different operator, or a verb that has since been withdrawn.

It says nothing about whether the operator can do the thing you wanted. A different verb may well do it, which is why this is a separate code from not_found: that one means the call was real and the thing it addressed is absent.

What it carries

• hint — the names that ARE registered for this method, plus a pointer to GET <endpoint>/schema. A mistyped listings for browse_listings self-corrects from the hint alone, with no catalogue round-trip.

What to do next

Read hint, or re-fetch GET <endpoint>/schema for the live catalogue, and call a name that exists. Do not report to your human that the operator cannot do the thing — you have not established that.

If the name was right but the method was wrong — a GET at an action’s path, a POST at a query’s — an operator that answers this code will normally answer method_not_allowed instead, carrying Allow. That is the signal the verb exists.

An operator is not required to answer this code at all. A path naming no verb it serves may simply be the bare 404 its web framework gives any unrouted path, with no problem document behind it — which is what the reference implementation does. The catalogue at GET <endpoint>/schema is the contract: read it and dial a name that is in it.

On the wire

{
  "type":   "https://kiosk.tech/problems/verb_not_found",
  "title":  "No such verb",
  "status": 404,
  "detail": "unknown query 'listings'",
  "code":   "verb_not_found"
}

This page documents the RFC 9457 type URI https://kiosk.tech/problems/verb_not_found. The URI is an identifier, not a locator a client should fetch: branch on the document’s code member. The normative definition lives in the error vocabulary of the Kiosk specification (§9 of the formal spec).