Intégrations & API
Vos systèmes restent en place. Nous nous y connectons.
Cette page s'adresse aux équipes IT et implémentation. Elle décrit comment les données circulent entre FastAssist24 et votre environnement, comment l'accès est protégé et quelles limites s'appliquent. Aucune clé, aucun jeton d'exemple, aucun détail d'implémentation interne.
Modèles d'échange
Trois façons d'échanger des données
Le modèle adapté dépend de votre environnement. Les trois ne s'excluent pas — en pratique, ils sont souvent utilisés ensemble.
| Modèle | Sens | Utilisation typique | Condition de votre côté |
|---|---|---|---|
| API REST | votre système → FastAssist24 | Créer des interventions, enregistrer des véhicules, vérifier la couverture et consulter l'état d'un dossier. | Votre système peut émettre des appels HTTPS sortants et transmettre une clé dans l'en-tête d'autorisation. |
| Webhooks | FastAssist24 → votre système | Recevoir les changements d'état d'un dossier sans interrogation répétée. | Vous mettez à disposition un point de terminaison HTTPS accessible qui reçoit et confirme la notification. |
| Import / export structuré | les deux sens | Échanger listes de véhicules, configurations de couverture et données d'intervention sous forme de fichiers. | Adapté aux environnements sans accès API direct ou avec une fenêtre d'export fixe. |
La référence complète des points de terminaison et les spécifications de champs sont fournies lors de la prise en charge technique. Elles ne sont pas publiées ici.
Accès et gestion des clés
Qui peut quoi, et avec quoi
L'accès à l'API est distinct de l'accès au portail. Les deux sont délimités par organisation.
- Clé par organisation ou partenaire
- Chaque organisation B2B et chaque partenaire dispose de sa propre clé. Une clé ne donne jamais accès aux données d'une autre organisation.
- Stockage haché
- Les clés sont conservées uniquement sous forme de hachage SHA-256. La clé elle-même n'est plus consultable après émission.
- Révocable par clé
- Une clé peut être révoquée individuellement sans interrompre les autres intégrations.
- Isolation des locataires
- Les données des organisations sont strictement séparées dans un modèle multi-locataires. Cette délimitation vaut pour l'API comme pour le portail.
- Accès basé sur les rôles
- Les rôles et droits sont séparés entre la plateforme, les organisations B2B et les prestataires.
- Journal d'audit par dossier
- Chaque changement d'état et chaque action est traçable avec sa chronologie complète — que cela passe par le portail ou par l'API.
Idempotence
Un appel répété ne crée pas un second dossier
Erreurs réseau, expirations et nouvelles tentatives font partie de toute intégration. Les écritures sont donc idempotentes : vous transmettez votre propre référence à la création. Si la même référence est présentée à nouveau, vous recevez le dossier existant au lieu d'un doublon.
Le même principe s'applique côté administratif au traitement des annulations et des remboursements.
- appel 1 · référence ORD-8841dossier créé
- expiration de votre côtéaucune confirmation reçue
- appel 2 · même référence ORD-8841le même dossier est renvoyé
- résultatun seul dossier, pas de double intervention
Vocabulaire d'état
Les états que traverse un dossier d'intervention
Voici le vocabulaire que votre système reçoit en retour. Il est identique à ce que vos collaborateurs voient dans le portail.
| État | Ce qui s'est passé |
|---|---|
| En attente | La demande est enregistrée et attend l'attribution à un prestataire. |
| Accepté | Un prestataire a accepté la mission. L'attribution est fixée. |
| En route | Le prestataire est en route vers le lieu indiqué. |
| Sur place | Le prestataire est sur place auprès du véhicule. |
| Terminé | L'intervention est terminée et le dossier peut être traité administrativement. |
| Annulé | Le dossier est arrêté. Le motif est consigné dans le dossier. |
Catégories de systèmes
Ce que les organisations connectent en pratique
Les catégories ci-dessous sont les plus fréquentes. Chaque connexion passe par l'un des trois modèles d'échange ci-dessus.
- Systèmes de flotte
- Plateformes ERP
- Plateformes sinistres
- Systèmes dispatch
- API partenaires
- Comptabilité & facturation
- Événements temps réel
- Import / Export
- Systèmes messagerie
- Partenaires location
- Prestataires paiement
- Reporting & analytics
Limites d'intégration
Ce que nous voulons établir au préalable
- La faisabilité d'une connexion dépend de votre environnement, des droits d'accès, du format des données et de la validation technique. Cela s'examine par projet et ne se promet pas à l'avance.
- Nous ne publions ni clés, ni jetons d'exemple, ni détails d'implémentation interne. La documentation technique passe par la prise en charge.
- Une intégration est d'abord testée dans un environnement délimité avant d'être branchée sur des dossiers réels.
- L'exactitude et la base légale des données fournies par votre système restent votre responsabilité. Les accords de traitement sont fixés contractuellement.
- Cette page décrit le fonctionnement actuel. Nous ne prenons ici aucun engagement sur des possibilités futures.
Parcours de mise en œuvre
De la prise en charge à la montée en charge progressive
- 01
Prise en charge opérationnelle
Nous cartographions votre prise en charge, dispatch, suivi et reporting actuels.
- 02
Configuration
Services, rôles, prestataires et règles SLA adaptés à votre fonctionnement.
- 03
Pilote contrôlé
Un environnement live délimité ; vous mesurez dispatch, acceptation et SLA sur vos propres interventions.
- 04
Montée en charge par phases
Extension par région, flotte ou service — avec reporting et positionnement d’intégration.
Conçu pour se connecter aux processus existants de flotte, leasing, assurance et mobilité. Lancement belge, conçu pour l’échelle européenne.
Laissez-nous examiner votre environnement.
Lors d'une prise en charge technique, nous passons en revue vos systèmes, vos droits d'accès et vos formats de données, et déterminons le modèle d'échange adapté.
Démo opérationnelle · 30 minutes · sans engagement