Philosophie de compatibilité¶
Puwapi vise la stabilité des surfaces publiques. En pratique :
- Les records DTO sont positionnels côté serveur : l'ajout d'un champ se fait en fin de structure et les champs existants ne changent pas de sens. Côté client, ignorez les champs inconnus plutôt que de casser.
- Les clés stables (clés de module pour le gating,
featureKeyIA, types de champs de formulaire, statuts Work) ne sont pas renommées à la légère. - Les nouvelles capacités arrivent par ajout (nouveaux endpoints, nouveaux champs optionnels), pas par rupture silencieuse.
Ce qui peut évoluer¶
- De nouveaux modules et de nouvelles routes apparaissent régulièrement.
- Des limites MVP sont levées au fil du temps (voir Support → Limites connues).
- Les quotas et inclusions par palier peuvent être ajustés (voir Pricing).
Repères de version connus¶
- Catalogue de pricing : versionné (un identifiant de version accompagne le catalogue, ce qui permet d'invalider les caches du Hub et de la Console).
- Modèle IA : les templates de features sont versionnés (une version « courante » active par feature) ; on peut créer et activer une nouvelle version sans casser l'existante.
- Articles Knowledge : chaque modification crée une version historisée, restaurable.
Bonnes pratiques d'intégrateur¶
- Codez défensivement : ne dépendez pas de l'ordre des champs JSON, tolérez les nouveaux.
- Épinglez ce qui doit l'être (par ex. la version du catalogue de pricing que vous affichez) et rafraîchissez volontairement.
- Surveillez vos webhooks et vos intégrations M2M après une évolution de plateforme.
Cette page tient lieu de note de version générale. Pour l'état détaillé d'un module (ce qui est livré, ce qui reste), reportez-vous à sa référence API et à Support → Limites connues.