Public API & OpenAPI : un contrat, pas un export CSV poli
Comment l’API /v1 expose assets, orders, documents, listings, auctions, events et le reste, pour les équipes qui ont de vrais besoins d’intégration.
Certains tenants vivront toute la journée dans ReVend OS. D’autres ont déjà un ERP, un WMS, un système financier ou une BI qui ne vont pas disparaître parce qu’un plus joli bouton est arrivé. La public API existe pour ces équipes-là : un accès structuré aux records opérationnels, sans diplomatie du copier-coller.
Ce que couvre l’API
La surface /v1 en production comprend assets, orders, evidence, documents, companies, contacts, adresses de company, warehouses, données de catalogue, sellable assets, listings, auctions, events, webhooks et import jobs. Ce n’est pas un endpoint de démo en veste de costume ; le contrat est généré, testé et exposé via OpenAPI.
Les import jobs enregistrent actuellement uniquement des demandes. Le traitement automatique et la validation des fichiers ne sont pas disponibles ; l’API renvoie processing_available: false. Utilisez les endpoints d’import direct pris en charge pour écrire des données.
OpenAPI
/api/v1/openapi.json publie le schéma de l’API. Les artefacts générés pour Postman, Bruno et le client TypeScript sont construits depuis le même registry. Docs, tests et routes réelles évitent ainsi de dériver vers trois avis distincts.
Garde-fous de cycle de vie
Les écritures API suivent les mêmes idées de cycle de vie que l’app : mises à jour sûres, transitions de statut, idempotence là où elle est requise, soft-delete ou archivage là où l’historique doit rester. Une API ne devrait pas devenir la porte de service pour faire ce que l’UI refuse à juste titre.
Qui devrait l’utiliser
Utilisez l’API quand un autre système possède une partie du workflow ou a besoin d’une synchronisation fiable. Utilisez les imports CSV quand le besoin est ponctuel. Tous les tableurs ne méritent pas OAuth et une réunion de cadrage.