Cette page sert de guide rapide pour les intégrateurs backend, mobile et web.
Elle liste les étapes métier dans le bon ordre, les endpoints à appeler, le payload minimal
et une réponse minimale représentative pour chaque endpoint clé.
Le superadmin prépare l'offre, puis le client se connecte, recherche et consulte le détail.
Attention
Point critique
Un départ n'apparaît en recherche que si la chaîne complète est active et cohérente.
Vue générale
Cette vue regroupe les repères rapides utiles avant d'entrer dans les étapes du flow.
Les providers SMS ci-dessous sont déjà disponibles pour les parcours OTP et peuvent être
choisis explicitement côté intégration cliente.
Provider SMS 1 — EasySend
Provider principal déjà intégré avec deux modes d'appel distincts selon le besoin
opérationnel ou les tests d'intégration.
sms_provider : easysend
sms_mode : rest ou http
Usage : OTP sur téléphone
Choix : utilisable directement depuis Swagger ou les apps clientes
Provider SMS 2 — TopMessage
Provider alternatif déjà intégré pour permettre un fallback applicatif côté mobile,
desktop ou backend quand EasySend n'est pas retenu.
sms_provider : topmessage
Mode : provider alternatif prêt à l'emploi
Usage : OTP sur téléphone
But : fallback explicite ou choix manuel depuis Swagger / intégrateurs
1
Connexion superadmin
Obtenir le bearer token qui servira à préparer toute l'offre transport. Ce token devra être envoyé dans l'en-tête Authorization: Bearer ... sur tous les endpoints d'administration suivants.
Représenter le lieu physique réel, partagé ou dédié. Une gare physique peut être partagée par plusieurs compagnies ou n'être utilisée que par une seule.
Créer la présence opérationnelle de la compagnie dans la gare. C'est ce niveau qui permet de dire quelle compagnie opère dans quelle gare, avec son point d'embarquement, son contact local ou son libellé d'affichage.
Définir la liaison théorique entre ville de départ et destination. Le trajet décrit la relation commerciale entre deux villes. Il ne correspond pas encore à un départ daté.
Rendre une offre visible et vendable pour la recherche client. Un départ ne pourra remonter dans la recherche que s'il est actif, cohérent avec le trajet et rattaché à des gares compagnie valides.
Créer un compte client avec email ou téléphone puis passer à la vérification OTP. Utiliser ce flow quand l'utilisateur n'existe pas encore dans le système.
Renvoyer un OTP pour un identifiant déjà connu dans le système. Utiliser ce flow quand le compte existe déjà et qu'il faut renvoyer un code sans recréer l'utilisateur.
Valider l'OTP et connecter immédiatement le client. La réponse retourne directement la session complète : access token, refresh token, user, rôles et permissions.
Déclencher un OTP de réinitialisation par email ou téléphone. Utiliser ce flow quand l'utilisateur a oublié son mot de passe et doit être reconnecté après validation du code.
Valider l'OTP de réinitialisation et reconnecter l'utilisateur. La réponse retourne immédiatement une nouvelle session utilisable côté mobile, web ou desktop.
Le client se connecte avant toute recherche ou consultation détaillée. À partir de cette étape, toutes les requêtes métier côté client doivent envoyer un bearer token valide.
Échanger un refresh token valide contre une nouvelle session. Utiliser ce flow quand l'access token a expiré mais que la session utilisateur doit rester ouverte.
Invalider le refresh token courant pour fermer proprement la session. Après cette étape, le refresh token ne doit plus être réutilisé par l'application cliente.
Récupérer les informations du compte actuellement connecté. Utiliser cet endpoint au démarrage de l'application cliente pour hydrater le profil et l'état de session.
Mettre à jour les informations personnelles après connexion. Les données complémentaires du client sont renseignées ici, pas au moment du register initial.
Permettre au client de remplacer son mot de passe actuel ou l'OTP utilisé comme mot de passe par défaut. À utiliser après connexion, notamment quand l'application invite l'utilisateur à personnaliser son mot de passe.
{
"success": true,
"message": "Mot de passe modifie",
"data": {
"success": true
}
}
19
Lister les destinations client
Alimenter une recherche assistée et forcer la sélection d'une ville normalisée. Sans le query parameter search, l'endpoint retourne la liste paginée de toutes les villes actives.
Bearer client
GET/api/locations/active?search=bou&page=1&limit=10Voir dans Swagger
Types attendus
Utiliser ces types et emplacements pour envoyer des valeurs conformes.
Champ
Type
Source
Obligatoire
Description
Authorization
string
header
oui
Bearer token du client connecte.
search
string
query
non
Texte saisi par le client pour filtrer les villes.
page
int
query
non
Numero de page.
limit
int
query
non
Nombre maximum de villes a retourner.
Payload minimal
Aucun body requis. Utiliser les query params ou l'identifiant dans l'URL.
Récupérer les valeurs backend officielles pour horaires, prix, tri et paliers de rayon. Ces données servent à alimenter les filtres de recherche de départ afin de garantir que les valeurs envoyées au backend soient conformes. Le front doit utiliser uniquement les rayons autorisés renvoyés par le backend : 10, 20, 30, 40, 50 et 60 km.
Chercher les départs dans un rayon autorisé autour du client pour une destination donnée. La recherche doit commencer à 10 km. Si aucun résultat n'est trouvé, le front doit demander confirmation au client avant de relancer la recherche avec le palier suivant : 20, puis 30, jusqu'à 60 km maximum. Les champs comme time_slots, price_ranges, company_ids et sort ne sont pas obligatoires pour une recherche simple.
Rappel de cohérence :
un départ doit pointer vers deux présences compagnie appartenant à la même compagnie que le trajet,
et les gares physiques associées doivent correspondre aux localisations d'origine et de destination du trajet.