Repull para plataformas: cómo funciona cuando tus clientes son los anfitriones

En la práctica, la plataforma nunca pide a sus usuarios que firmen nada con nosotros, nunca les muestra nuestra marca salvo un enlace de atribución en la página Connect y nunca les entrega una credencial. Tu usuario pulsa “conectar Airbnb” dentro de tu producto, completa un flujo alojado con tu marca y vuelve. Su cuenta es ya una cuenta conectada más en tu espacio de trabajo.

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

• Muchas cuentas por canal. Las cuentas de anfitrión de Airbnb, las propiedades de Booking.com y las cuentas de Vrbo de todos tus usuarios conviven en tu espacio de trabajo. GET /v1/connect/{provider} las lista en accounts, y DELETE /v1/connect/{provider} admite un accountId para desconectar la cuenta de un usuario sin tocar las demás.
• Cada evento indica su cuenta. Las entregas de webhook llevan un bloque account —provider y externalAccountId, el id propio del proveedor— y la misma cuenta en las cabeceras X-Repull-Account y X-Repull-Account-Id.
• Cada registro indica su cuenta. GET /v1/reservations, /v1/conversations y /v1/reviews llevan account en cada fila y /v1/properties lleva accounts; los cuatro admiten ?account=provider:externalAccountId para leer los datos de un usuario.
• Una clave para todo el espacio de trabajo. La clave es tuya y lee todas las cuentas conectadas. Los alcances limitan lo que puede hacer, no lo que puede ver, que es justo lo que quieres cuando la clave solo vive en tus servidores.

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

Las dos funcionan técnicamente. La segunda es mejor de verdad en un caso: un cliente lo bastante grande como para querer su propia relación, su propia factura y su propia continuidad si alguna vez deja tu producto. Para todos los demás, la primera tiene menos fricción y menos credenciales en tu base de datos.

Se configura una vez en /dashboard/settings/connect y se aplica a todos los canales que conectan tus usuarios. El flujo en sí tiene la misma forma que Stripe Connect o Plaid Link: tu servidor crea una sesión y lee un estado, y nunca toca una credencial de canal.

• Pagina con cursores. Los endpoints de listado pesados se paginan por clave, así que el coste por página se mantiene constante por mucho que avances. ?offset= existe como alias para paginación poco profunda y es la herramienta equivocada para un recorrido completo.
• Escribe por lotes. PATCH /v1/availability/batch para valores de calendario de muchas propiedades, POST /v1/listings/pricing/bulk para decisiones de precio y POST /v1/listings/status para la activación. Una llamada, muchas propiedades, y los fallos parciales se informan elemento a elemento en lugar de hacer fallar el lote.
• Envía una clave de idempotencia. Toda escritura que crea algo admite Idempotency-Key. Con volumen de plataforma, un timeout no es un caso raro: es un martes cualquiera.
• Suscríbete, no sondees. Un endpoint POST /v1/webhooks para tu espacio de trabajo, con registro de entregas, reenvío y un endpoint de prueba por tipo de evento para que puedas construir el gestor antes del primer evento real.

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

Que no haya ninguna cifra en esta página no es timidez. Los acuerdos con plataformas varían en un orden de magnitud según cuántos clientes finales hay detrás, qué canales usan y quién lleva el soporte de primer nivel, y una cifra publicada para uno de esos casos engaña activamente para los demás. Lo que sí puedes comprobar tú antes de cualquier conversación es el consumo: los endpoints de uso informan de lo que ha usado un espacio de trabajo y de a qué tiene derecho, así que puedes modelar tu propia economía con cifras reales en lugar de con las nuestras.

1. 1Regístrate una vez. Tu espacio de trabajo y su clave de API son las únicas credenciales de Repull en tu sistema; guarda la clave en tus servidores.
2. 2Para cada usuario, crea una sesión de Connect con POST /v1/connect, limitando allowedProviders a los canales que soporta tu producto.
3. 3Pasa tu id de usuario como state. Cuando termina, connect.session.completed devuelve ese state con la cuenta que conectó: guarda la cuenta asociada al usuario.
4. 4Suscribe un endpoint de webhook con POST /v1/webhooks y dirige cada evento por su bloque account. Usa los endpoints de prueba y de reenvío para construir el gestor antes de que llegue un evento real.
5. 5Lee a través de los endpoints entre canales siempre que puedas, para que añadir un canal más adelante sea un cambio de configuración y no una reescritura.

La versión técnica más profunda —autenticación, tipos de eventos de webhook, sandbox, cobertura por canal— está en las preguntas y respuestas para plataformas SaaS. El detalle canal por canal está en las guías de Airbnb, Booking.com y Vrbo, y la referencia completa en la documentación.

La mayoría de plataformas hereda lo que ya usan sus clientes, lo que en la práctica significa una variedad de sistemas de gestión de propiedades y no uno solo. Cada uno tiene su propio modelo de autenticación, sus propios nombres de campos y sus propios límites: las guías de Guesty, Hostaway, Hospitable, Lodgify, OwnerRez, Smoobu y Beds24 explican lo que expone cada sistema y lo que te cuesta mantenerlo, y la matriz de cobertura los compara uno al lado del otro.