Preisvorschläge von Käufern: was der Agent entschieden hat und was nicht

Auf dem Marktplatz schlagen Käufer Preise vor. Der hinterlegte Mindestpreis ist die einzige Verhandlungsgrundlage des Agenten. Fehlt zu einem Artikel ein Mindestpreis, entscheidet er über ein Preisangebot nicht, sondern übergibt es an einen Menschen. Diese abgegebenen Angebote sind der Arbeitsvorrat — und sie verfallen, wenn sie niemand ansieht.

Die Angebotsliste des Posteingangs zeigt Preisangebote mit der Entscheidung, die der Agent getroffen hat — oder ohne Entscheidung, wenn er das Angebot übergeben hat. Wo er entschieden hat, nennt decisionPriceCents gegebenenfalls den Preis. Der Filter needs_human reduziert sie auf das, was ein Mensch entscheiden muss.

Was dieser Fall voraussetzt

• Ein Marktplatzkanal mit erteilter Einwilligung. Ohne sie kommen keine Preisangebote beim Agenten an.
• Hinterlegte Mindestpreise. Sie sind die einzige Verhandlungsgrundlage des Agenten; ohne sie entscheidet er nicht.
• Jemanden, der den Filter regelmäßig ansieht. Ein Angebot trägt ein Ablaufdatum.
• Eine Linie für Gegenangebote. Wie weit ein Kollege unter den Mindestpreis geht, ist eine kaufmännische Entscheidung, keine technische.

Der Ablauf

Die Tabelle nennt je Stufe den zuständigen Aufruf und das, was danach vorliegt. Die Begründung, warum die Stufe nicht übersprungen werden kann, steht darunter.

Warum jede Stufe nötig ist

1. Die Mindestpreise nachsehen. GET /agent/items/prices listet minPriceCents je itemKey mit updatedAt. Bevor ein Kollege ein Angebot beurteilt, sieht er, auf welcher Grundlage der Agent entschieden hätte — und ob diese Grundlage noch aktuell ist.
2. Die offenen Angebote filtern. GET /agent/inbox/offers kennt status mit pending, decided und needs_human. Jedes Angebot trägt itemPriceCents, offerPriceCents, expiresAt, decision mit accept, decline, counter, record oder handoff und gegebenenfalls decisionPriceCents.
3. Das Gespräch lesen. GET /agent/inbox/conversations/{conversationId} zeigt den Verlauf mit actions, findings und suggestedReply. So sieht der Kollege den Verlauf, bevor er antwortet.
4. Antworten. POST /agent/inbox/conversations/{conversationId}/reply setzt voraus, dass das Gespräch zuvor mit POST /agent/inbox/conversations/{conversationId}/takeover übernommen wurde, und liefert deliveryStatus. Auf einem Postfach- oder Marktplatzkanal wird die Antwort zur Zustellung eingereiht, auf der Website gilt sie sofort als zugestellt.
5. Als gelesen markieren. POST /agent/inbox/conversations/{conversationId}/read setzt unreadCount zurück. Das klingt nebensächlich, hält aber den Arbeitsvorrat ehrlich: Was gelesen und beantwortet ist, verschwindet aus dem Blick derer, die nach Offenem suchen.

curl -H 'X-Api-Key: <API_KEY>' \
  'https://api.tapinomahub.com/hub/index.php/agent/inbox/offers?status=needs_human&limit=25'

Was am Ende vorliegt

Am Ende hat jedes Preisangebot eine Entscheidung — vom Agenten, wo der Mindestpreis sie trägt, und von einem Kollegen, wo er es nicht tut. Kein Angebot verfällt, weil es in der falschen Liste stand.

Wo das in der Dokumentation steht

Die verbindlichen Feldlisten, Fehlercodes und Beispielantworten stehen im OpenAPI-Vertrag dieser Fläche unter docs.tapinomahub.com (tapinoma-agent). Alle Anwendungsfälle nach Fläche und Rolle geordnet: Übersicht der Anwendungsfälle.