Repull per le piattaforme: come funziona quando i tuoi clienti sono gli host

In pratica la piattaforma non chiede mai ai suoi utenti di firmare nulla con noi, non mostra mai il nostro marchio tranne un link di attribuzione sulla pagina Connect e non consegna mai loro una credenziale. Il tuo utente clicca “collega Airbnb” nel tuo prodotto, completa un flusso ospitato con il tuo marchio e torna. Il suo account è ora un account collegato in più nel tuo spazio di lavoro.

// 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.

• Molti account per canale.Gli account host Airbnb, le strutture Booking.com e gli account Vrbo di tutti i tuoi utenti stanno uno accanto all'altro nel tuo spazio di lavoro. GET /v1/connect/{provider} li elenca in accounts, e DELETE /v1/connect/{provider} accetta un accountIdper scollegare l'account di un utente senza toccare gli altri.
• Ogni evento indica il proprio account. Le consegne webhook riportano un blocco account — provider e externalAccountId, l'id del provider — e lo stesso account negli header X-Repull-Account e X-Repull-Account-Id.
• Ogni record indica il proprio account. GET /v1/reservations, /v1/conversations e /v1/reviews riportano account su ogni riga e /v1/properties riporta accounts; tutti e quattro accettano ?account=provider:externalAccountId per leggere i dati di un utente.
• Una chiave per tutto lo spazio di lavoro. La chiave è tua e legge ogni account collegato. Gli ambiti limitano cosa può fare, non cosa può vedere: è proprio quello che vuoi quando la chiave vive solo sui tuoi server.

// 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.

Entrambi funzionano tecnicamente. Il secondo è davvero migliore in un caso: un cliente abbastanza grande da volere un proprio rapporto, una propria fattura e una propria continuità se un giorno lasciasse il tuo prodotto. Per tutti gli altri il primo ha meno attrito e meno credenziali nel tuo database.

Si imposta una volta su /dashboard/settings/connect e vale per ogni canale che collegano i tuoi utenti. Il flusso in sé ha la stessa forma di Stripe Connect o Plaid Link: il tuo server crea una sessione e legge uno stato, senza mai toccare una credenziale di canale.

• Pagina con i cursori. Gli endpoint di elenco più pesanti sono paginati per chiave, quindi il costo per pagina resta costante per quanto in profondità tu vada. ?offset= esiste come alias per la paginazione leggera ed è lo strumento sbagliato per una scansione completa.
• Scrivi a lotti. PATCH /v1/availability/batch per i valori di calendario su molte proprietà, POST /v1/listings/pricing/bulk per le decisioni di prezzo e POST /v1/listings/statusper l'attivazione. Una chiamata, molte proprietà, con i fallimenti parziali riportati elemento per elemento invece di far fallire il lotto.
• Invia una chiave di idempotenza. Ogni scrittura che crea qualcosa accetta Idempotency-Key. A volumi da piattaforma un timeout non è un caso limite: è un martedì qualsiasi.
• Iscriviti, non fare polling. Un endpoint POST /v1/webhooks per il tuo spazio di lavoro, con log delle consegne, reinvio e un endpoint di test per ogni tipo di evento, così puoi costruire il gestore prima del primo evento reale.

# 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_...'

Il motivo per cui su questa pagina non c'è un numero non è riservatezza. Gli accordi con le piattaforme cambiano di un ordine di grandezza a seconda di quanti clienti finali ci sono dietro, quali canali usano e chi si occupa del supporto di primo livello, e una cifra pubblicata per uno di questi casi è attivamente fuorviante per gli altri. Quello che puoi verificare da solo prima di qualsiasi conversazione è il consumo: gli endpoint di utilizzo riportano cosa ha usato uno spazio di lavoro e a cosa ha diritto, così puoi modellare la tua economia su numeri reali invece che sui nostri.

1. 1Registrati una volta. Il tuo spazio di lavoro e la sua chiave API sono le uniche credenziali Repull nel tuo sistema; tieni la chiave sui tuoi server.
2. 2Per ogni utente, crea una sessione Connect con POST /v1/connect, limitando allowedProviders ai canali supportati dal tuo prodotto.
3. 3Passa il tuo id utente come state. Quando ha finito, connect.session.completed restituisce quello state con l'account collegato: salva l'account associato all'utente.
4. 4Iscrivi un endpoint webhook con POST /v1/webhooks e indirizza ogni evento in base al suo blocco account. Usa gli endpoint di test e di reinvio per costruire il gestore prima che arrivi un evento reale.
5. 5Leggi tramite gli endpoint trasversali ai canali ogni volta che puoi, così aggiungere un canale in futuro sarà un cambio di configurazione e non una riscrittura.

La versione tecnica più approfondita — autenticazione, tipi di eventi webhook, sandbox, copertura per canale — è nelle domande e risposte per piattaforme SaaS. Il dettaglio canale per canale è nelle guide di Airbnb, Booking.com e Vrbo, e il riferimento completo è nella documentazione.

La maggior parte delle piattaforme eredita ciò che usano già i propri clienti, cioè in pratica una varietà di sistemi di gestione delle proprietà e non uno solo. Ognuno ha il proprio modello di autenticazione, i propri nomi dei campi e i propri limiti: le guide di Guesty, Hostaway, Hospitable, Lodgify, OwnerRez, Smoobu e Beds24 spiegano cosa espone ciascun sistema e quanto ti costa mantenerlo, e la matrice di copertura li confronta fianco a fianco.