Robaws AI
Robaws & AI
Notre vision
Chez Robaws, nous sommes convaincus que votre ERP ne doit pas être un jardin clos. Vos devis, projets, articles, clients et planning sont vos données — et la chose la plus précieuse que vous puissiez faire avec vos données en 2026, c'est de laisser des logiciels, et de plus en plus l'IA, travailler avec elles pour vous.
C'est pourquoi tout ce que vous voyez dans l'interface de Robaws est également disponible via notre API REST publique (v2). Les assistants IA, agents et outils d'automatisation peuvent dès aujourd'hui lire et écrire dans votre compte, de manière sécurisée et entièrement sous votre contrôle. Nous n'attendons pas un « bouton IA » magique — les fondations sont déjà là, et vous pouvez construire dessus dès maintenant.
Au fil du temps, nous lancerons également des fonctions natives d'IA au sein même de Robaws (établir des devis, résumer des projets, signaler des risques, répondre à des questions sur votre pipeline). Nous les déployons délibérément par scénario d'usage plutôt que comme un gadget, afin que chaque fonction mérite sa place. Jusque-là — et en complément de ces fonctions — l'API est la porte vers tout.
⚠️ Attention : Ce guide est écrit pour des développeurs. Si des termes comme HTTP Basic auth, credentials encodés en base64, requêtes PATCH idempotentes et merge-patch content types ne vous disent rien, c'est le moment de vous faire aider. Rendez-vous à la fin — nous vous orientons vers un partenaire qui fait cela au quotidien.
Comment l'IA se connecte à Robaws
L'API Robaws est une interface RESTful HTTPS standard. Chaque outil IA, framework d'agents ou middleware capable d'envoyer des requêtes HTTP authentifiées et de traiter du JSON peut s'y intégrer. Il n'y a pas de SDK propriétaire à installer — si ça parle HTTP, ça parle Robaws.
Base host (toujours) :
https://app.robaws.comTous les endpoints se trouvent sous /api/v2/. La spécification OpenAPI complète et lisible par machine est publiée ici :
https://app.robaws.com/public/api-docs/robawsPointez votre outillage LLM, votre générateur de code ou votre framework d'agents sur cette spec, et il pourra décrire lui-même chaque ressource, méthode et schéma de payload disponible.
Authentification
L'API utilise l'authentification HTTP Basic sur TLS. Vous vous authentifiez avec une API key et un API secret, combinés sous la forme key:secret et encodés en base64 dans un en-tête Authorization.
# L'en-tête est : 'Basic ' + base64("APIKEY:APISECRET") curl -s https://app.robaws.com/api/v2/clients?limit=1 \ -H "Authorization: Basic $(printf '%s' 'APIKEY:APISECRET' | base64)" \ -H "Accept: application/json"
Un 200 OK confirme que vos credentials sont valides. Un 401 Unauthorized signifie que la paire key/secret est erronée ou révoquée. Traitez le secret comme un mot de passe : ne le placez jamais dans du code côté client, des applications navigateur ou quoi que ce soit qu'un utilisateur final puisse inspecter. Conservez-le dans un secret manager côté serveur ou une variable d'environnement, et faites-le tourner si vous soupçonnez une fuite.
Une lecture minimale
curl -s https://app.robaws.com/api/v2/offers?limit=10 \ -H "Authorization: Basic <base64 credentials>" \ -H "Accept: application/json"
Une écriture minimale
curl -s -X POST https://app.robaws.com/api/v2/clients \ -H "Authorization: Basic <base64 credentials>" \ -H "Content-Type: application/json" \ -d '{ "name": "Demo Construction", "language": "nl", "currency": "EUR", "status": "prospect" }'
Mettre à jour des records (c'est ici que beaucoup se trompent)
Les mises à jour partielles utilisent PATCH et requièrent un content type spécifique. Un body application/json ordinaire est refusé avec un 415 Unsupported Media Type. Utilisez :
Content-Type: application/merge-patch+jsoncurl -s -X PATCH https://app.robaws.com/api/v2/offers/12345 \ -H "Authorization: Basic <base64 credentials>" \ -H "Content-Type: application/merge-patch+json" \ -d '{ "status": "won", "statusSuccessPercentage": 100 }'
Tenez également compte du fait que les objets imbriqués (comme une adresse) sont remplacés, pas fusionnés en profondeur — envoyer un objet imbriqué partiel écrase l'objet complet. Envoyez toujours la structure imbriquée complète.
Ce que vous pouvez lire et écrire
Les mêmes ressources que vous gérez dans l'interface sont disponibles comme endpoints, dont :
/api/v2/clientset/api/v2/clients/{id}/contacts/api/v2/articles/api/v2/posts(modèles réutilisables et pilotés par paramètres pour les lignes d'articles)/api/v2/offerset/api/v2/offers/{id}/line-items/api/v2/projects
C'est une surface suffisante pour qu'un agent IA établisse un devis, enrichisse un client, réconcilie un projet ou résume votre pipeline — entièrement de manière programmatique.
⚠️ L'accès à l'API est déterminé par les rôles utilisateurs — lisez ceci attentivement
C'est la partie que la plupart des gens négligent, et c'est la plus importante dès que vous laissez l'IA écrire dans votre compte.
Votre API key hérite des droits de l'utilisateur Robaws auquel elle est liée. Une API key n'est pas une credential maîtresse distincte et toute-puissante — elle agit en tant que cet utilisateur. Ce que cet utilisateur peut voir et modifier dans l'interface est exactement ce que l'API key peut voir et modifier. Rien de plus.
Les conséquences pratiques :
- Lecture versus écriture est une décision de rôle, pas une décision d'API. Vous voulez un assistant IA capable de lire votre pipeline mais jamais de le modifier ? Liez sa key à un utilisateur dont le rôle donne un accès en lecture seule aux modules concernés. L'API renvoie alors des données sur
GET, mais refuse les tentativesPOST/PATCH/DELETEsur les ressources hors des droits de cet utilisateur. - Limitez selon le principe du moindre privilège. Ne pointez pas un agent IA expérimental sur une key liée à un compte administrateur. Créez un utilisateur API distinct avec un rôle limité exactement aux modules et droits dont l'intégration a besoin. Si l'agent ne doit créer que des devis en brouillon, il ne doit pas pouvoir supprimer des clients ni toucher à la facturation.
- Une key, un objectif. Utilisez des utilisateurs API distincts (et donc des keys distinctes) pour des intégrations distinctes. Ainsi, vous pouvez révoquer ou faire tourner l'accès d'une intégration sans casser les autres, et votre audit trail montre quel utilisateur/agent a fait quelle modification.
- Auditing. Comme chaque key est liée à un utilisateur, les actions via l'API sont attribuables à cet utilisateur. Utilisez cela pour surveiller ce que vos intégrations IA font réellement.
En résumé : le rôle que vous attribuez à l'utilisateur API est votre politique de contrôle d'accès pour l'IA. Configurez-le délibérément avant de confier une key à un outil autonome. Donnez à un agent une key admin avec droits d'écriture et il pourra tout modifier ; donnez-lui un utilisateur limité en lecture seule et il restera sagement dans les lignes.
Où va l'IA dans Robaws
L'API est la base. Par-dessus, nous lançons des capacités natives d'IA au sein même de Robaws, priorisées sur de vrais cas d'usage clients plutôt que sur le hype. Les directions probables comprennent notamment l'aide à l'établissement de devis, les résumés de projets et de pipeline, et l'interrogation de vos données en langage naturel — mais nous ne lançons chacune d'elles que lorsqu'elle est réellement utile pour un scénario concret auquel nos clients sont confrontés.
Vous avez un cas d'usage spécifique que vous aimeriez voir automatisé ? Faites-le-nous savoir. Les scénarios réels de vraies entreprises de construction sont précisément ce qui guide notre roadmap.
Vous voulez un partenaire qui met cela en place pour vous ?
Construire une intégration IA robuste et sécurisée — authentification correcte, utilisateurs API correctement délimités, gestion des erreurs, idempotence, et la logique IA proprement dite par-dessus — c'est un vrai travail d'ingénierie. Vous préférez ne pas faire cela en interne ? Collaborez alors avec un partenaire qui connaît l'API Robaws sur le bout des doigts.
Nous recommandons Libaro — ils vous aident à concevoir et construire votre intégration Robaws + IA de bout en bout.
Mis à jour le : 06/07/2026
Merci !
