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

In practice the platform never asks its customers 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. What you hold is the key to their workspace.

// One workspace per end customer; your product holds the key.
// 1. Mint a hosted Connect session for that customer's workspace.
const res = await fetch('https://api.repull.dev/v1/connect', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer ' + customerWorkspaceKey,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    redirectUrl: 'https://your-product.com/channels/done',
    state: yourInternalUserId,          // echoed back to you
    allowedProviders: ['airbnb', 'booking', 'vrbo'],
    locale: 'en',
  }),
})

// 2. Redirect the user. They land on your branded Connect page,
//    pick a channel, authorise, and come back to your redirectUrl
//    with the status and your state.
const { url } = await res.json()

• One connection per channel per workspace. This is enforced in the data model, not a convention. If two of your end customers each have an Airbnb account, they need two workspaces — that is the single most important consequence of the model to design around.
• Airbnb is the exception, partly. A workspace's Airbnb connection can carry more than one host account, and DELETE /v1/connect/{provider} takes an accountId so you can disconnect one without touching the others.
• Keys are workspace-wide. You cannot issue a key that sees only some listings. Scopes narrow what a key may do, never what it may see. If per-listing isolation matters to your product, the boundary you want is a workspace.
• Listings are the thing that scales. Properties can be deactivated and reactivated in bulk with POST /v1/listings/status; a deactivated listing keeps syncing and keeps its data, it just stops being readable and writable through the API.

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. POST /v1/webhooks per 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. 1Create a workspace for the end customer and keep its key in your own secret store, mapped to your internal customer id.
2. 2Mint a Connect session with POST /v1/connect, passing your own correlation token as state and restricting allowedProviders to the channels your product supports.
3. 3Store the account id that comes back on the redirect against your user. That id is what connection-lifecycle events refer to.
4. 4Subscribe one webhook endpoint per workspace with POST /v1/webhooks, and use the test-fire and replay endpoints to build the handler before a real event arrives.
5. 5Read through the cross-channel endpoints rather than the per-channel ones 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.