API partenaire Chauffleet: intégrez les réservations VTC dans votre propre système

L'API réservation VTC de Chauffleet permet à toute plateforme externe d'envoyer, gérer et facturer des courses en temps réel, directement depuis ses propres outils, sans développer sa propre flotte ni son propre dispatch.

Concrètement: une agence de voyages, un hôtel, un portail corporate ou une plateforme événementielle peut aujourd'hui se connecter à une société VTC partenaire Chauffleet et réserver des transferts pour ses clients en quelques appels REST. Aucun double saisie. Aucun intermédiaire supplémentaire. Le transporteur reçoit la course directement dans son tableau de bord Chauffleet.

Les 5 modules de l'API partenaire Chauffleet

La documentation officielle de l'API est organisée en sujets fonctionnels distincts. Chaque module couvre une étape précise du cycle de vie d'une intégration partenaire.

1. Réseau: gérer les connexions avec les transporteurs

Avant de pouvoir créer une réservation, un partenaire doit établir un lien avec le transporteur concerné. Ce lien est bilatéral: les deux parties doivent l'accepter.

Les endpoints du module réseau permettent de:

L'état d'un lien suit une logique d'acceptation à deux niveaux. Tant que les deux parties n'ont pas confirmé, les endpoints de réservation restent bloqués. Une fois le lien établi, l'accès aux courses, au catalogue et aux estimations de prix devient disponible.

Ce modèle est important pour les intégrateurs: il évite qu'un partenaire puisse créer des réservations chez un transporteur sans son consentement explicite.

2. Catalogue: découvrir les prestations et options disponibles

Chaque transporteur Chauffleet configure ses propres prestations (berline, van, SUV...) et options (siège bébé, bagages supplémentaires, accueil en enseigne...). Ces services sont accessibles via le module catalogue.

L'endpoint GET /partner/catalog/v1/tenants/{tenantId}/overview retourne:

Cette étape est indispensable avant la création d'une réservation: le prestationId récupéré ici est un champ obligatoire dans le corps de la requête de création de course.

3. Estimation: calculer le prix avant de s'engager

Avant de confirmer une réservation à un client, une plateforme doit pouvoir afficher un tarif précis. Le module d'estimation répond à ce besoin.

L'endpoint POST /partner/estimate/v1/tenants/{tenantId}/route prend en entrée:

La réponse contient:

Cette décomposition par section est utile pour les trajets multi-étapes (gare, hôtel, aéroport), où chaque segment peut avoir un tarif différent selon la grille du transporteur.

4. Clients: gérer le fichier passagers côté partenaire

Le module clients permet à un partenaire de maintenir sa propre base de passagers, indépendante du CRM du transporteur. Un client créé via l'API reste propriété du partenaire: le transporteur ne peut pas y accéder directement.

Les opérations disponibles:

Le clientId retourné à la création est ensuite utilisé comme référence obligatoire dans les réservations. Cette séparation entre fichier client partenaire et fichier client transporteur est un choix architectural clair: chaque acteur garde la maîtrise de ses données passagers.

5. Réservations: créer, consulter, annuler et suivre les paiements

C'est le coeur de l'API. Quatre endpoints couvrent l'ensemble du cycle de vie d'une réservation.

Créer une réservation (POST /partner/bookings/v1/tenants/{tenantId})

Les champs obligatoires sont: identifiant client, étapes textuelles, coordonnées GPS des étapes, date de prise en charge, identifiant de prestation, mode de paiement, tolérance de paiement et creationId.

La clé creationId mérite une attention particulière. Il s'agit d'un identifiant UUID fourni par l'appelant. Si la même valeur est réutilisée lors d'un retry, l'API retourne la réservation déjà créée sans en créer une seconde. C'est une protection essentielle contre les doublons en cas d'erreur réseau ou de timeout côté client.

Les modes de paiement disponibles sont: cash, nfc (terminal FleetPay), link (lien de paiement envoyé au client) et other. La tolérance peut être prepaid, postpaid ou onaction.

La réponse inclut l'identifiant de réservation, le statut initial (pending) et, selon le mode de paiement choisi, une URL de paiement ou les données nécessaires au flux Stripe.

Consulter une réservation (GET /partner/bookings/v1/tenants/{tenantId}/{bookingId})

Cet endpoint retourne l'ensemble des données d'une course: statut, chauffeur assigné, véhicule (marque, modèle, couleur, immatriculation), étapes, heure d'arrivée estimée, montant, TVA et remise éventuelle.

Une particularité: cet endpoint reste accessible même si le lien partenaire-transporteur a été rompu depuis la création de la réservation. L'historique est préservé.

Annuler une réservation (POST /partner/bookings/v1/tenants/{tenantId}/{bookingId}/cancel)

L'annulation prend une raison optionnelle en corps de requête. Elle aussi reste accessible après rupture du lien, ce qui garantit qu'un partenaire peut toujours annuler ses propres courses.

Le cycle de vie d'une réservation suit 6 états possibles: pending, confirmed, en_route, ongoing, finished, cancelled.

Suivre le paiement (GET /partner/bookings/v1/tenants/{tenantId}/{bookingId}/payment)

Cet endpoint expose le statut de paiement détaillé: montant dû, montant encaissé, type de paiement, statut Stripe et, pour les paiements NFC, l'identifiant de l'intent Stripe.

Comment fonctionne le processus de liaison partenaire-transporteur

Le processus de connexion entre un partenaire et un transporteur suit une logique d'invitation bilatérale. Deux cas de figure se présentent.

Cas 1: le partenaire initie la connexion

Le partenaire envoie une demande de liaison via POST /partner/network/v1/links/{tenantId}. L'état du lien passe à accept: partner -- le transporteur doit encore valider. Du côté du transporteur, une invitation apparaît dans son interface Chauffleet. Une fois acceptée, l'état passe à accept: both et les endpoints de réservation deviennent disponibles.

Cas 2: le transporteur invite le partenaire

Le transporteur peut également prendre l'initiative depuis l'interface Chauffleet. L'état initial est alors accept: tenant. Le partenaire voit l'invitation dans GET /partner/network/v1/links/pending et l'accepte via le même endpoint POST /partner/network/v1/links/{tenantId}.

Ce mécanisme garantit qu'aucune réservation ne peut transiter vers un transporteur sans accord mutuel préalable. Pour les équipes commerciales Chauffleet, c'est aussi un levier simple pour intégrer des partenaires distributeurs qui souhaitent revendre des courses sans gérer leur propre flotte.

Pour approfondir la logique de dispatch côté transporteur, cet article sur le dispatch VTC intelligent et l'intégration API transport donne un bon aperçu de comment les courses entrantes sont traitées.

Pourquoi cette approche change quelque chose pour les VTC

Les plateformes de mise en relation imposent leur interface, leur marque et leur commission. Une API partenaire directe inverse ce rapport.

Côté transporteur, chaque réservation arrivant via un partenaire API est une course qui ne passe pas par une plateforme tierce. La relation client reste entre le transporteur et l'agence partenaire. La commission ne part pas vers un intermédiaire.

Côté partenaire, l'intégration directe donne une maîtrise complète du parcours client: tarification affichée avant confirmation, suivi de statut en temps réel, annulation programmatique. Plus besoin d'intermédiaire humain pour chaque course.

Isabelle dirige une plateforme de conciergerie d'entreprise à Paris. Avant l'intégration API, son équipe passait par trois applications différentes pour gérer les transferts de ses clients: une pour le booking, une pour le suivi, une pour la facturation. Depuis la connexion à Chauffleet, tout se passe dans un seul outil. Les 40 transporteurs partenaires reçoivent leurs courses instantanément, et Isabelle a une vue unifiée sur l'ensemble des réservations depuis son tableau de bord.

Chaque partenaire peut ainsi construire exactement l'expérience qu'il veut pour ses clients, avec les données du transporteur Chauffleet en temps réel, sans dépendre d'une interface imposée de l'extérieur.

C'est là que réside la vraie valeur de la gestion clients Chauffleet dans ce modèle: le transporteur garde sa propre relation client, et le partenaire garde la sienne. Les deux acteurs grandissent ensemble sans se marcher dessus.

FAQ

Qu'est-ce qu'une API partenaire VTC? Une API partenaire VTC est une interface de programmation qui permet à une plateforme externe (agence, hôtel, portail corporate) d'envoyer des réservations à une société de transport VTC depuis son propre système, sans intervention manuelle.

Faut-il être client Chauffleet pour utiliser l'API partenaire? Non. L'API partenaire est accessible à tout intégrateur externe qui souhaite distribuer des courses pour le compte de transporteurs utilisant Chauffleet. Le partenaire crée un compte dédié distinct du compte transporteur.

Combien de transporteurs peut-on connecter via l'API? Un partenaire peut gérer des liens avec autant de transporteurs qu'il le souhaite. Chaque lien est indépendant et nécessite une acceptation mutuelle. Le partenaire accède ensuite au catalogue, aux estimations et aux réservations de chaque transporteur connecté.

Comment sont gérées les annulations? Via l'endpoint dédié POST /partner/bookings/v1/tenants/{tenantId}/{bookingId}/cancel. L'annulation reste accessible même si le lien avec le transporteur a été rompu depuis. Une raison optionnelle peut être transmise.

Quels modes de paiement sont supportés? L'API supporte quatre modes: espèces (cash), terminal NFC FleetPay (nfc), lien de paiement Stripe (link) et autre (other). La tolérance de paiement peut être prépayée, post-payée ou déclenchée sur action.

SEO Checklist

AI Search Optimization Checklist

Engagement Checklist