Repull pour les plateformes SaaS : 20 questions, avec les réponses

Oui. C’est exactement ce pour quoi le parcours Connect hébergé est fait : chacun de tes utilisateurs finaux autorise son propre compte de canal (par exemple son propre compte hôte Airbnb) dans ton workspace Repull. Chaque compte connecté a son propre suivi, ses propres jetons et sa propre surveillance d’état.

Docs : Connect (multicanal), OAuth Connect, Connect Widget.

Il n’y a pas de plafond technique sur les comptes connectés. Les offres sont facturées à l’annonce : Free couvre jusqu’à 3 annonces, Starter coûte 99 $/mois avec 10 annonces incluses et 5 $ par annonce à partir de la 11e jusqu’à 100, et au-delà de 100 annonces (là où arrive une plateforme qui sert beaucoup d’hôtes), c’est une offre Custom avec un tarif au volume et un seul workspace partenaire pour tous tes clients.

Docs : Tarifs, Repull pour les plateformes.

Oui. Les jetons d’accès et de rafraîchissement sont stockés par compte connecté, totalement isolés. Si un utilisateur révoque l’accès, seul son compte est concerné : tu reçois un webhook account.disconnected pour ce compte avec un motif lisible par machine, et tous les autres continuent de se synchroniser.

Oui. Passe ton identifiant utilisateur interne en state quand tu crées la session Connect. Quand l’utilisateur a terminé, le webhook connect.session.completed te renvoie ce state avec le compte connecté, donc tu fais le lien une seule fois. Ensuite, chaque livraison de webhook contient un bloc account (provider et externalAccountId, l’identifiant propre au fournisseur) ainsi que les en-têtes X-Repull-Account et X-Repull-Account-Id, et les réservations, conversations et avis portent le même compte sur chaque enregistrement.

Docs : OAuth Connect, Webhooks.

Oui. GET /v1/connect liste toutes les connexions de ton workspace (id, fournisseur, statut, id de compte externe). Il existe aussi un endpoint d’état dédié par canal, par exemple GET /v1/channels/airbnb/connection, qui renvoie chaque compte Airbnb connecté avec son statut et le motif de la dernière déconnexion, conçu pour être interrogé depuis un écran d’état.

Docs : Référence de l’API, Connect.

Oui, tel quel :

1. 1POST /v1/connect renvoie l’URL d’une session hébergée (valable 30 minutes)
2. 2Tu y rediriges ton utilisateur
3. 3L’utilisateur autorise Airbnb (ou choisit un autre canal dans le sélecteur)
4. 4L’utilisateur revient sur ton redirectUrl avec status=connected&accountId=… et ton state
5. 5Les webhooks account.created et connect.session.completed partent
6. 6La connexion est active ; la synchronisation initiale démarre toute seule en arrière-plan
7. 7Tu lis les données via l’API et reçois les webhooks au fil de l’eau

Docs : Connect, Quickstart.

Oui, de bout en bout : la connexion Airbnb, la gestion des permissions et des scopes (lecture seule, messagerie ou accès complet), l’échange de jetons, les jetons de rafraîchissement et l’expiration sont gérés par Repull. Quand un rafraîchissement est refusé ou que l’accès est révoqué en amont, le compte est signalé et tu reçois account.disconnected avec un motif (refresh_token_rejected, auth_expired, revoked_upstream, manual_disconnect) pour renvoyer l’utilisateur dans le même parcours hébergé et qu’il se réauthentifie.

Docs : Canal Airbnb.

Oui. Il n’y a pas de sandbox séparée : chaque compte reçoit une clé sk_live_* à l’inscription (offre gratuite, sans carte), donc tu testes directement sur la vraie API : tu crées de vrais logements, réservations et abonnements webhook, puis tu les supprimes quand tu as fini. Le système de webhooks a ses propres outils de test : POST /v1/webhooks/{id}/test/{event_type} envoie des payloads d’exemple réalistes pour n’importe quel type d’événement, plus des endpoints de ping et de rejeu et des journaux de livraison complets.

Une réserve honnête : Airbnb ne propose pas de comptes hôtes de sandbox, donc un test OAuth de bout en bout demande une vraie connexion Airbnb, quel que soit l’environnement. Tout ce qui suit (webhooks, formats de données, gestion des erreurs) se teste entièrement avec des événements d’exemple, sans connexion Airbnb réelle.

Docs : Gérer les webhooks.

Oui.Les pages Connect hébergées sont en marque blanche par workspace : nom de l’app, logo (versions claire et sombre), couleurs principale et d’accent pour les deux thèmes, e-mail de support en pied de page, tes propres URL de conditions et de confidentialité, une URL de redirection par défaut et une langue par défaut. L’URL reste sur connect.repull.dev et la page affiche un lien « Powered by Repull ».

Docs : Connect Widget.

Oui. Un utilisateur peut avoir plusieurs connexions à la fois (Airbnb, Booking.com, Vrbo et un PMS), et un workspace peut avoir de nombreux comptes par canal : de nombreux hôtes Airbnb, de nombreux établissements Booking.com, de nombreux comptes Vrbo. La seule limite aujourd’hui : une connexion par logiciel de gestion locative (PMS) par workspace. La session hébergée peut afficher un sélecteur multicanal ou être limitée à certains fournisseurs avec allowedProviders.

Docs : Connect (multicanal), Couverture PMS.

Oui. DELETE /v1/connect/{provider} révoque le jeton OAuth quand le canal le permet, supprime les identifiants stockés et arrête toutes les tâches de synchronisation de cette connexion. Passe un accountId pour déconnecter un compte sans toucher aux autres sur le même canal.

Oui. GET /v1/listings est paginé par curseur et filtrable avec ?channel=airbnb|booking|vrbo. Chaque annonce porte un tableau channels[] avec la plateforme, l’identifiant d’origine du logement sur le canal (externalId) et le statut d’activation et de synchronisation, donc tu sais toujours à quel canal appartient chaque logement et quel est son identifiant natif. Extensions optionnelles avec ?include=content,details,amenities.

Docs : Lister les logements, Détails d’un logement, Contenu et détails d’une annonce.

Airbnb : oui, via POST /v1/reviews/{id}/reply, quand l’hôte s’est connecté avec un accès complet. Airbnb n’autorise l’écriture sur les avis qu’avec sa permission de gestion des logements, donc les connexions en lecture seule et messagerie lisent les avis mais ne peuvent pas y répondre. Booking.com et Vrbo : en test. Les réponses passent par le même endpoint, mais elles n’ont pas encore été prouvées sur un vrai avis.

Docs : Avis, OAuth Connect.

Oui. GET /v1/reviews est un flux d’avis unifié sur tous les canaux (Airbnb, Booking.com, Vrbo) avec des filtres par plateforme, annonce, plage de notes, avec ou sans réponse, et avis du voyageur ou de l’hôte. Les mises à jour, réponses de l’hôte comprises, arrivent sur les mêmes enregistrements.

Les webhooks review.created et review.responded te préviennent quand un avis arrive ou reçoit une réponse. L’endpoint est servi depuis notre base de données, jamais par un appel en direct au canal, donc l’interroger ne coûte presque rien.

Docs : Lister les avis.

Le catalogue à jour est sur Types d’événements webhook et en format lisible par machine sur GET /v1/webhooks/event-types (avec des payloads d’exemple). Événements actuels :

Les livraisons sont signées en HMAC-SHA256 (façon Stripe), avec nouvelles tentatives, rejeu et journaux complets : Vérifier les signatures, Nouvelles tentatives, Gérer les webhooks.

Les synchronisations sont des tâches en arrière-plan. Connecter un compte lance en parallèle plusieurs pipelines (annonces, calendrier et prix, messages, avis, transactions) sur notre infrastructure de files d’attente ; tu n’as rien à gérer. La durée de la synchronisation initiale dépend surtout des limites du canal lui-même, donc elle augmente avec la taille du compte : les gros portefeuilles se terminent en arrière-plan pendant que la connexion est déjà utilisable.

Les lectures sont paginées par curseur jusqu’à 100 éléments par page (stable à n’importe quelle profondeur), donc 100 000 avis représentent environ 1 000 appels, presque rien face à la limite par défaut de 600 requêtes par minute. Les changements arrivent par webhooks, donc tu n’as jamais à tout re-parcourir.

Docs : Limites de requêtes, Idempotence.

Synchronisées. Repull synchronise les données des canaux dans notre propre base de données et sert l’API à partir de là. C’est un choix de conception central : des lectures rapides et cohérentes qui ne bloquent jamais sur l’API d’Airbnb et ne subissent pas ses limites, et ton app continue de fonctionner même quand la source a des soucis. Les réponses incluent un bloc data_freshness (last_synced_at, indicateur de données périmées) pour que tu saches toujours à quel point les données sont fraîches.

À l’annonce, avec un quota d’appels API par offre, pas à la réservation, à l’avis, au webhook ou au compte connecté. Free : 0 $, jusqu’à 3 annonces, 1 000 appels/mois. Starter : 99 $/mois, 10 annonces incluses, 5 $ par annonce à partir de la 11e jusqu’à 100, 100 000 appels/mois, webhooks inclus. Custom : plus de 100 annonces avec un tarif au volume et des limites d’API adaptées à ton intégration.

Docs : Tarifs, Crédits et consommation.

C’est le terrain de l’offre Custom. À cette échelle, le prix dépend du nombre d’annonces par utilisateur et du volume d’API, et on le construit comme un partenariat de plateforme, pas comme un tarif par siège. Envoie-nous tes chiffres et tu recevras une proposition concrète : comment fonctionnent les tarifs plateforme.

Starter inclut le support par e-mail ; Custom inclut le support prioritaire par e-mail et, pour une grosse intégration de plateforme, on peut ouvrir un canal partagé avec notre équipe d’ingénierie.

Au quotidien, l’API est conçue pour que tu te débrouilles seul : chaque réponse d’erreur contient un request_id, un code lisible par machine, un champ fix avec l’étape suivante exacte et un lien direct vers la documentation des erreurs.