Repull für Plattformen: So funktioniert es, wenn deine Kunden die Gastgeber sind

In der Praxis bittet die Plattform ihre Nutzer nie, etwas mit uns zu unterschreiben, zeigt ihnen unsere Marke nur als Attributionslink auf der Connect-Seite und gibt ihnen nie Zugangsdaten. Dein Nutzer klickt in deinem Produkt auf „Airbnb verbinden“, durchläuft einen gehosteten Flow in deinem Branding und kommt zurück. Sein Konto ist jetzt ein weiteres verbundenes Konto in deinem Workspace.

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

• Viele Konten pro Kanal. Die Airbnb-Gastgeberkonten, Booking.com-Unterkünfte und Vrbo-Konten aller deiner Nutzer leben zusammen in deinem Workspace. GET /v1/connect/{provider} listet sie unter accounts, und DELETE /v1/connect/{provider} akzeptiert eine accountId, um das Konto eines Nutzers zu trennen, ohne die anderen anzufassen.
• Jedes Event nennt sein Konto. Webhook-Zustellungen tragen einen account-Block — provider und externalAccountId, die eigene ID des Anbieters — und dasselbe Konto in den Headern X-Repull-Account und X-Repull-Account-Id.
• Jeder Datensatz nennt sein Konto. GET /v1/reservations, /v1/conversations und /v1/reviews tragen account in jeder Zeile, und /v1/properties trägt accounts; alle vier akzeptieren ?account=provider:externalAccountId, um die Daten eines Nutzers zu lesen.
• Ein Key für den ganzen Workspace. Der Key gehört dir und liest alle verbundenen Konten. Scopes begrenzen, was er tun kann, nicht, was er sehen kann — genau das willst du, wenn der Key nur auf deinen Servern liegt.

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

Technisch funktionieren beide. Das zweite ist in einem Fall wirklich besser: bei einem Kunden, der groß genug ist, um eine eigene Beziehung, eine eigene Rechnung und eigene Kontinuität zu wollen, falls er dein Produkt irgendwann verlässt. Für alle anderen hat das erste weniger Reibung und weniger Zugangsdaten in deiner Datenbank.

Du konfigurierst das einmal unter /dashboard/settings/connect, und es gilt für jeden Kanal, den deine Nutzer verbinden. Der Flow selbst hat dieselbe Form wie Stripe Connect oder Plaid Link: Dein Server erstellt eine Session und liest einen Status aus, und er fasst nie Kanal-Zugangsdaten an.

• Paginiere mit Cursors. Die schweren Listen-Endpunkte sind key-basiert paginiert, also bleiben die Kosten pro Seite konstant, egal wie tief du gehst. ?offset= gibt es als Alias für kurze Seitenwechsel, und für einen kompletten Durchlauf ist es das falsche Werkzeug.
• Schreib im Batch. PATCH /v1/availability/batch für Kalenderwerte über viele Objekte, POST /v1/listings/pricing/bulk für Preisentscheidungen und POST /v1/listings/status für die Aktivierung. Ein Aufruf, viele Objekte, und Teilfehler werden pro Eintrag gemeldet, statt den ganzen Batch scheitern zu lassen.
• Schick einen Idempotency-Key mit. Jeder Schreibvorgang, der etwas anlegt, akzeptiert Idempotency-Key. Bei Plattformvolumen ist ein Timeout kein Sonderfall, sondern ein ganz normaler Dienstag.
• Abonnieren statt pollen. Ein POST /v1/webhooks-Endpunkt für deinen Workspace, mit Zustellprotokoll, erneuter Zustellung und einem Test-Endpunkt pro Event-Typ, damit du den Handler baust, bevor das erste echte Event ankommt.

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

Dass auf dieser Seite keine Zahl steht, ist keine Zurückhaltung. Plattformverträge unterscheiden sich um eine Größenordnung, je nachdem, wie viele Endkunden dahinterstehen, welche Kanäle sie nutzen und wer den First-Level-Support übernimmt, und eine veröffentlichte Zahl für einen dieser Fälle ist für die anderen aktiv irreführend. Was du vor jedem Gespräch selbst prüfen kannst, ist der Verbrauch: Die Usage-Endpunkte zeigen, was ein Workspace genutzt hat und worauf er Anspruch hat, also kannst du deine eigene Wirtschaftlichkeit mit echten Zahlen modellieren statt mit unseren.

1. 1Registriere dich einmal. Dein Workspace und sein API-Key sind die einzigen Repull-Zugangsdaten in deinem System; bewahre den Key auf deinen Servern auf.
2. 2Erstelle für jeden Nutzer eine Connect-Session mit POST /v1/connect und beschränke allowedProviders auf die Kanäle, die dein Produkt unterstützt.
3. 3Übergib deine Nutzer-ID als state. Wenn er fertig ist, gibt connect.session.completed diesen state mit dem verbundenen Konto zurück: Speichere das Konto bei diesem Nutzer.
4. 4Abonniere einen Webhook-Endpunkt mit POST /v1/webhooks und leite jedes Event über seinen account-Block weiter. Nutze die Test- und Wiederholungs-Endpunkte, um den Handler zu bauen, bevor ein echtes Event ankommt.
5. 5Lies über die kanalübergreifenden Endpunkte, wo immer es geht, damit ein zusätzlicher Kanal später eine Konfigurationsänderung ist und kein Neuschreiben.

Die tiefere technische Version — Authentifizierung, Webhook-Event-Typen, Sandbox, Abdeckung pro Kanal — steht im Q&A für SaaS-Plattformen. Die Details pro Kanal findest du in den Leitfäden zu Airbnb, Booking.com und Vrbo, und die vollständige Referenz in der Dokumentation.

Die meisten Plattformen übernehmen, was ihre Kunden schon nutzen, und das heißt in der Praxis mehrere Property-Management-Systeme, nicht nur eines. Jedes hat sein eigenes Authentifizierungsmodell, eigene Feldnamen und eigene Grenzen: Die Leitfäden zu Guesty, Hostaway, Hospitable, Lodgify, OwnerRez, Smoobu und Beds24 erklären, was jedes System bereitstellt und was dich die Pflege kostet, und die Abdeckungsmatrix vergleicht sie nebeneinander.