FZ-011 · INTÉGRATIONS
PosPlugin
Les données de vente des systèmes de point de vente via une seule API, pour les créateurs d’applications.
- Statut
- En développement
- Étape du pipeline
- VALIDATION
- Secteur
- INTÉGRATIONS
- Cible d’autonomie
- NIVEAU 4 · AUTO-OPTIMISANT
- Construit avec
- 3 en ligne · 2 prévus
Le problème
Chaque application qui a besoin de données de vente construit et répare une intégration distincte pour chaque système de point de vente.
Ce qu’il fait
PosPlugin est conçu pour connecter chaque caisse une seule fois et donner à votre application ses données via une seule API.
Comment ça marche
- Connectez le POS d’un commerçant avec un identifiant ou une clé d’API ; rien n’y est écrit
- L’IA fait correspondre ses champs à un modèle propre, et une personne confirme tout ce dont elle n’est pas sûre
- Votre application lit commandes, paiements, menus et sites via une seule API REST et des webhooks
Un bac à sable gratuit pour les développeurs au lancement ; tarification en direct par site connecté.
Connectez un nouveau commerçant en une demi-heure au lieu de semaines de travail d’intégration.
Aujourd’huiLe site et la liste d’accès anticipé sont ouverts. Les connecteurs, le moteur de correspondance et l’API sont en construction.
Le film
Objectifs
- Exploitation autonome
- L’entretien des intégrations est la cible de l’automatisation. Connecter le système de point de vente d’un commerçant doit se faire en une demi-heure guidée plutôt que par un projet sur mesure, et le garder connecté ne doit mobiliser personne : un moniteur surveille chaque synchronisation pour détecter dérives de schéma et échecs, propose la correction de la correspondance et indique aux opérations ce qui a cassé et pourquoi.
- Intelligence
- Un modèle lit la documentation API, les spécifications ou des exemples de charges utiles d’un POS et propose la correspondance de chaque champ avec un modèle de données unique, avec un score de confiance sur chaque champ. Il propose et une personne confirme : une correspondance à faible confiance ne passe jamais en production seule, et chaque décision est conservée dans un journal d’audit. Le déplacement des données est du code ordinaire.
- Croissance
- Porté par les développeurs. D’abord un bac à sable gratuit avec des données de POS de test, puis une tarification par site connecté, fixée avec les premiers clients. La restauration est le premier secteur. La croissance, ce sont les sites de commerçants connectés, comptés à partir du premier client qui n’est pas un pilote.
Le détail technique
Une couche d’intégration pour les systèmes de point de vente. Elle se connecte au POS d’un commerçant par OAuth ou clé d’API, récupère des échantillons de données en lecture seule, et un modèle fait correspondre les champs du POS à un modèle de données unique (commandes, paiements, articles du catalogue, sites) avec un score de confiance sur chaque champ ; une personne confirme les cas incertains. Les applications lisent ensuite chaque commerçant via une seule API REST et un seul flux de webhooks, la charge utile d’origine du POS étant conservée sur chaque enregistrement, et réécrivent les commandes lorsque le POS le permet. Un moniteur surveille les dérives de schéma et les synchronisations en échec. Les numéros de carte n’y transitent jamais. Le premier secteur est la restauration. Aujourd’hui, il existe le site posplug.in et sa liste d’accès anticipé ; les connecteurs, le moteur de correspondance, l’API unifiée et le bac à sable sont conçus et pas encore écrits.
Voir aussi
Issues du même socle.
- Colonizer. Transforme les issues GitHub en pull requests pour les développeurs, sur leur propre machine.
- Cratefield. Un backend pour les créateurs qui préfèrent compiler plutôt que configurer.
- Owlpost. Une API e-mail pour les applications et les agents AI, avec ses propres boîtes de réception.
- SupportGenius. Des réponses d’assistance tirées de vos docs ; tout ce qui reste sans réponse va à votre équipe.