Repull pour les plateformes : comment ça marche quand tes clients sont les hôtes

En pratique, la plateforme ne demande jamais à ses utilisateurs de signer quoi que ce soit avec nous, ne leur montre jamais notre marque à part un lien d'attribution sur la page Connect, et ne leur remet jamais d'identifiant. Ton utilisateur clique sur “connecter Airbnb” dans ton produit, passe par un flux hébergé à tes couleurs et revient. Son compte est désormais un compte connecté de plus dans ton espace de travail.

// One workspace — yours — and one key for every user you onboard.
// 1. Mint a Connect session for this user, with your user id as state.
const res = await fetch('https://api.repull.dev/v1/connect', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer ' + process.env.REPULL_API_KEY,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    redirectUrl: 'https://your-product.com/channels/done',
    state: userId,                      // comes back to you
    allowedProviders: ['airbnb', 'booking', 'vrbo-login'],
  }),
})
const { url } = await res.json()

// 2. Redirect the user. They connect on your branded Connect page and
//    come back with ?status=connected&state=<userId>. The
//    connect.session.completed webhook carries the same state and the
//    account they connected — store that account against the user.

• Plusieurs comptes par canal. Les comptes hôtes Airbnb, les établissements Booking.com et les comptes Vrbo de tous tes utilisateurs cohabitent dans ton espace de travail. GET /v1/connect/{provider} les liste dans accounts, et DELETE /v1/connect/{provider} accepte un accountIdpour déconnecter le compte d'un utilisateur sans toucher aux autres.
• Chaque événement indique son compte. Les livraisons webhook portent un bloc account — provider et externalAccountId, l'id propre au fournisseur — et le même compte dans les en-têtes X-Repull-Account et X-Repull-Account-Id.
• Chaque enregistrement indique son compte. GET /v1/reservations, /v1/conversations et /v1/reviews portent account sur chaque ligne et /v1/properties porte accounts ; les quatre acceptent ?account=provider:externalAccountIdpour lire les données d'un utilisateur.
• Une clé pour tout l’espace de travail.La clé est à toi et lit tous les comptes connectés. Les périmètres limitent ce qu'elle peut faire, pas ce qu'elle peut voir— c'est exactement ce que tu veux quand la clé ne vit que sur tes serveurs.

// Every webhook event names the connected account it came from.
app.post('/repull/webhooks', (req, res) => {
  const event = verify(req)                 // HMAC over the raw body
  const { provider, externalAccountId } = event.account ?? {}
  const userId = accountsToUsers.get(provider + ':' + externalAccountId)
  // …hand event.data to that user's inbox, calendar or CRM
  res.sendStatus(200)
})
// The provider's account id is also on the X-Repull-Account header,
// so you can shard before parsing the body.

Les deux fonctionnent techniquement. Le second est vraiment meilleur dans un cas : un client assez gros pour vouloir sa propre relation, sa propre facture et sa propre continuité s'il quitte un jour ton produit. Pour tous les autres, le premier crée moins de friction et met moins d'identifiants dans ta base.

Ça se règle une fois dans /dashboard/settings/connectet ça s'applique à tous les canaux que tes utilisateurs connectent. Le flux lui-même a la même forme que Stripe Connect ou Plaid Link : ton serveur crée une session et lit un statut, sans jamais toucher à un identifiant de canal.

• Pagine avec des curseurs. Les endpoints de liste lourds sont paginés par clé, donc le coût par page reste constant quelle que soit la profondeur. ?offset=existe comme alias pour la pagination peu profonde et n'est pas le bon outil pour un parcours complet.
• Écris par lots. PATCH /v1/availability/batch pour les valeurs de calendrier sur de nombreux biens, POST /v1/listings/pricing/bulk pour les décisions de prix et POST /v1/listings/statuspour l'activation. Un appel, beaucoup de biens, avec les échecs partiels signalés élément par élément au lieu de faire échouer le lot.
• Envoie une clé d’idempotence. Toute écriture qui crée quelque chose accepte Idempotency-Key. À l'échelle d'une plateforme, un timeout n'est pas un cas limite, c'est un mardi comme un autre.
• Abonne-toi, ne sonde pas. Un endpoint POST /v1/webhookspour ton espace de travail, avec journal de livraison, rejeu et un endpoint de test par type d'événement pour construire ton gestionnaire avant le premier vrai événement.

# What is connected, for a support screen.
curl https://api.repull.dev/v1/connect \
  -H 'Authorization: Bearer sk_live_...'

# What this workspace has consumed, for your own metering.
curl https://api.repull.dev/v1/usage/summary \
  -H 'Authorization: Bearer sk_live_...'

S'il n'y a aucun chiffre sur cette page, ce n'est pas par coquetterie. Les accords avec les plateformes varient d'un ordre de grandeur selon le nombre de clients finaux derrière, les canaux qu'ils utilisent et qui assure le support de premier niveau, et un chiffre publié pour l'un de ces cas induit en erreur pour les autres. Ce que tu peux vérifier toi-même avant toute discussion, c'est la consommation : les endpoints d'usage indiquent ce qu'un espace de travail a utilisé et ce à quoi il a droit, donc tu peux modéliser ton économie à partir de vrais chiffres plutôt que des nôtres.

1. 1Inscris-toi une fois. Ton espace de travail et sa clé d'API sont les seuls identifiants Repull dans ton système ; garde la clé sur tes serveurs.
2. 2Pour chaque utilisateur, crée une session Connect avec POST /v1/connect, en limitant allowedProviders aux canaux que ton produit prend en charge.
3. 3Passe ton id utilisateur en state. Quand il a fini, connect.session.completed renvoie ce state avec le compte qu'il a connecté : enregistre le compte rattaché à l'utilisateur.
4. 4Abonne un endpoint webhook avec POST /v1/webhooks et achemine chaque événement selon son bloc account. Utilise les endpoints de test et de rejeu pour construire ton gestionnaire avant qu'un vrai événement arrive.
5. 5Lis via les endpoints multicanaux dès que possible, pour qu'ajouter un canal plus tard soit un changement de configuration et pas une réécriture.

La version technique détaillée — authentification, types d'événements webhook, sandbox, couverture par canal — est dans les questions-réponses pour plateformes SaaS. Le détail canal par canal est dans les guides Airbnb, Booking.com et Vrbo, et la référence complète dans la doc.

La plupart des plateformes héritent de ce que leurs clients utilisent déjà, c'est-à-dire en pratique de plusieurs logiciels de gestion plutôt que d'un seul. Chacun a son modèle d'authentification, ses noms de champs et ses limites : les guides Guesty, Hostaway, Hospitable, Lodgify, OwnerRez, Smoobu et Beds24détaillent ce que chaque système expose et ce qu'il te coûte à maintenir, et la matrice de couverture les compare côte à côte.