Offres de prix des acheteurs : ce que l’agent a décidé, et ce qu’il n’a pas décidé

Sur la marketplace, des acheteurs proposent des prix. Le prix plancher enregistré est la seule base de négociation de l’agent. Sans prix plancher pour un article, il ne tranche pas une offre de prix mais la transmet à un humain. Ces offres transmises forment la file de travail — et elles expirent si personne ne les regarde.

La liste des offres de la boîte montre les offres avec la décision prise par l’agent — ou sans décision s’il a transmis l’offre. Là où il a décidé, decisionPriceCents indique le cas échéant le prix. Le filtre needs_human la réduit à ce qu’un humain doit trancher.

Ce que ce cas suppose

• Un canal marketplace avec consentement accordé. Sans lui, aucune offre n’atteint l’agent.
• Des prix plancher enregistrés. Ils sont la seule base de négociation de l’agent ; sans eux, il ne décide pas.
• Quelqu’un qui consulte le filtre régulièrement. Une offre porte une date d’expiration.
• Une ligne pour les contre-offres. Jusqu’où un collègue descend sous le plancher est une décision commerciale, non technique.

Le déroulement

Le tableau indique pour chaque étape l’appel compétent et ce qui existe ensuite. La justification de l’étape figure en dessous.

Pourquoi chaque étape est nécessaire

1. Consulter les prix plancher. GET /agent/items/prices liste minPriceCents par itemKey avec updatedAt. Avant de juger une offre, le collègue voit sur quelle base l’agent aurait décidé — et si elle est encore à jour.
2. Filtrer les offres ouvertes. GET /agent/inbox/offers connaît status avec pending, decided et needs_human. Chaque offre porte itemPriceCents, offerPriceCents, expiresAt, decision avec accept, decline, counter, record ou handoff, et le cas échéant decisionPriceCents.
3. Lire la conversation. GET /agent/inbox/conversations/{conversationId} montre l’historique avec actions, findings et suggestedReply. Le collègue voit ainsi l’historique avant de répondre.
4. Répondre. POST /agent/inbox/conversations/{conversationId}/reply suppose que la conversation a d’abord été reprise avec POST /agent/inbox/conversations/{conversationId}/takeover, et renvoie deliveryStatus. Sur un canal messagerie ou marketplace, la réponse est mise en file pour livraison ; sur le site, elle est aussitôt considérée comme livrée.
5. Marquer comme lu. POST /agent/inbox/conversations/{conversationId}/read remet unreadCount à zéro. Cela paraît secondaire mais garde la file de travail fidèle : ce qui est lu et traité disparaît de la vue de ceux qui cherchent l’ouvert.

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

Ce que l’on obtient

Au final, chaque offre a une décision — de l’agent là où le prix plancher la porte, d’un collègue là où il ne la porte pas. Aucune offre n’expire pour avoir été dans la mauvaise liste.

Où cela figure dans la documentation

Les listes de champs contractuelles, les codes d’erreur et les réponses d’exemple se trouvent dans le contrat OpenAPI de cette surface, à l’adresse docs.tapinomahub.com (tapinoma-agent). Tous les cas d’usage classés par surface et par rôle : aperçu des cas d’usage.