Repull for platforms: how it works when your customers are the hosts

In practice the platform never asks its users to sign anything with us, never shows them our brand except for one attribution link on the Connect page, and never hands them a credential. Your user clicks “connect Airbnb” inside your product, completes a hosted flow wearing your branding, and comes back. Their account is now one more connected account in your 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.

• Many accounts per channel. Airbnb host accounts, Booking.com properties and Vrbo accounts from all of your users sit side by side in your workspace. GET /v1/connect/{provider} lists them in accounts, and DELETE /v1/connect/{provider} takes an accountId to disconnect one user's account without touching the others.
• Every event names its account. Webhook deliveries carry an account block — provider and externalAccountId, the provider's own id — and the same account on the X-Repull-Account and X-Repull-Account-Id headers.
• Every record names its account. GET /v1/reservations, /v1/conversations and /v1/reviews carry account on every row and /v1/properties carries accounts; all four take ?account=provider:externalAccountIdto read one user's data.
• One key, workspace-wide. The key is yours and reads every connected account. Scopes narrow what it may do, not what it may see — which is what you want when the key only ever lives on your servers.

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

Both work technically. The second is genuinely better in one case: a customer large enough to want their own relationship, their own invoice and their own continuity if they ever leave your product. For everyone else the first is less friction and fewer credentials in your database.

Set it once at /dashboard/settings/connect and it applies to every channel your users connect. The flow itself is the same shape as Stripe Connect or Plaid Link: your server mints a session and reads a status, and never touches a channel credential.

• Paginate with cursors. The heavy list endpoints are keyset-paginated, so page cost stays constant however deep you go. ?offset= exists as an alias for shallow paging and is the wrong tool for a full sweep.
• Write in batches. PATCH /v1/availability/batch for calendar values across many properties, POST /v1/listings/pricing/bulk for pricing decisions, and POST /v1/listings/status for activation. One call, many properties, partial failures reported per item rather than failing the batch.
• Send an idempotency key. Every write that creates something takes Idempotency-Key. At platform volume a timeout is not an edge case, it is Tuesday.
• Subscribe, do not poll. One POST /v1/webhooks endpoint for your workspace, with delivery logs, replay and a test-fire endpoint per event type so you can build the handler before the first real event.

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

The reason there is no number on this page is not coyness. Platform arrangements differ by an order of magnitude depending on how many end customers sit behind them, which channels they use and who carries first-line support — and a figure published for one of those shapes is actively misleading for the others. What you can verify yourself before any conversation is the consumption: the usage endpoints report what a workspace has used and what it is entitled to, so you can model your own economics from real numbers rather than from ours.

1. 1Sign up once. Your workspace and its API key are the only Repull credentials in your system; keep the key on your servers.
2. 2For each user, mint a Connect session with POST /v1/connect, restricting allowedProviders to the channels your product supports.
3. 3Pass your user id as state. When they finish, connect.session.completed returns that state with the account they connected — store the account against the user.
4. 4Subscribe one webhook endpoint with POST /v1/webhooks and route every event by its account block. Use the test-fire and replay endpoints to build the handler before a real event arrives.
5. 5Read through the cross-channel endpoints wherever you can, so adding a channel later is a configuration change rather than a rewrite.

The deeper technical version of this — auth handling, webhook event types, sandboxing, per-channel coverage — is in the SaaS platform Q&A. Channel-by-channel detail lives in the Airbnb, Booking.com and Vrbo guides, and the full reference is in the docs.

Most platforms inherit whatever their customers already run, which in practice means a spread of property management systems rather than a single one. Each has its own auth model, its own field names and its own limits — the Guesty, Hostaway, Hospitable, Lodgify, OwnerRez, Smoobu and Beds24 guides each set out what that system exposes and what it costs you to keep, and the coverage matrix compares them side by side.