A API do Vrbo: como funciona o acesso e o que podes construir hoje

Vale a pena esclarecer a confusão, porque é daí que vem a maior parte da má informação. O Vrbo está dentro do Expedia Group, e o Expedia Group tem várias superfícies para programadores que não são a mesma coisa. A que importa se geres alojamento local ou crias software para ele é a conectividade própria do Vrbo: a integração que o software de um gestor usa para manter tarifas, disponibilidade e reservas alinhadas com o Vrbo. Uma página que te diz para obteres uma chave da API do Vrbo em dez minutos está a descrever outra coisa.

• Anúncios: detalhes do anúncio, tarifas, configuração do alojamento e disponibilidade.
• Reserva online: gerar orçamentos, verificar disponibilidade, reservar, atualizar registos de reserva.
• Avaliações: partilhar avaliações da propriedade para mostrar no Vrbo.
• Pedidos: obter os pedidos de aluguer enviados através do Vrbo.

O Expedia Group descreve o resultado de forma simples: com conectividade por API, tarifas, disponibilidade e reservas atualizam-se dinamicamente do teu software para o Vrbo, e preços, calendários e políticas de cancelamento são controlados a partir do teu software e não da extranet do Vrbo. A direção importa: a conectividade do Vrbo é feita para que o teu sistema seja a fonte de verdade e envie os dados, um modelo mental diferente do OAuth de pedido e consentimento do Airbnb.

curl -X POST https://api.repull.dev/v1/connect \
  -H 'Authorization: Bearer sk_live_...' \
  -H 'Content-Type: application/json' \
  -d '{
    "redirectUrl": "https://yourapp.com/connected",
    "allowedProviders": ["vrbo-login"],
    "accessType": "messaging"
  }'

# Send the host to the returned url. They sign in with their Vrbo
# account and map their units; the import starts when they confirm.

curl 'https://api.repull.dev/v1/channels/vrbo/reservations?limit=50' \
  -H 'Authorization: Bearer sk_live_...'

# Page with the cursor from pagination.nextCursor.
# ?offset= is accepted as a first-class alias for shallow paging.

Os endpoints de canal respondem a “o que tem o Vrbo”. Para tudo o que vais mostrar a uma pessoa — o hóspede, o pagamento, a política com que a estadia foi reservada —, lê antes a superfície entre canais, onde uma reserva do Vrbo chega com a mesma forma de uma do Airbnb.

# The same reservation, with everything on it, from the
# cross-channel read — guest, price breakdown, policy code.
curl 'https://api.repull.dev/v1/reservations?platform=vrbo&limit=50' \
  -H 'Authorization: Bearer sk_live_...'

# Conversations and reviews take the same filter:
#   /v1/conversations?platform=vrbo
#   /v1/reviews?platform=vrbo
# Properties filters on the channel it is published to:
#   /v1/properties?channel=vrbo

• Importação. Nada é importado até o anfitrião associar as unidades. Depois chegam primeiro as próximas reservas e as mensagens dos últimos 30 dias, e o resto do histórico segue em segundo plano.
• Paginação. Os dois endpoints são paginados por cursor; ?offset= é aceite para paginação curta e é incompatível com cursor.
• Anúncios inativos. Um anúncio desativado continua a sincronizar, mas sai destas leituras, contagens e cursores incluídos. Encontra-os com GET /v1/listings?status=inactive.
• Criar reservas. POST /v1/reservations está limitado a direct, website e owner. Uma estadia do Vrbo pertence ao canal e chega por sincronização; criá-la localmente só iria chocar com a sincronização seguinte.

A fundo sobre os outros dois: o guia da API do Airbnb e o guia da API do Booking.com.

Vale a pena ser concreto sobre a diferença, porque “usamos o iCal e pronto” é uma decisão de que as equipas se arrependem ao fim de dois meses. Um feed de calendário dá-te um intervalo de datas e uma etiqueta. Não te diz quem reservou, quanto pagou, o que perguntou na conversa, que política se aplica se cancelar, nem se o preço no anúncio ainda é o que querias cobrar. Tudo isso está por trás da conectividade.

• Uma caixa de entrada unificada ou um assistente de IA que responde a hóspedes e pedidos do Vrbo ao lado do Airbnb e do Booking.com, sem o anfitrião mudar de PMS.
• Um único feed de reservas a que não falta nenhum canal: as reservas do Vrbo chegam com a mesma forma normalizada que as do Airbnb e do Booking.com.
• Relatórios de ocupação, ADR e receitas em que a parte do Vrbo é mesmo contada em vez de estimada.
• Um CRM de hóspedes que reconhece o mesmo hóspede em todos os canais em vez de criar um terceiro perfil.
• Gestão de avaliações do Vrbo, Airbnb e Booking.com a partir de um só sítio.
• Relatórios a proprietários que batem certo, porque as estadias do Vrbo estão no mesmo registo que tudo o resto.

Começa pela documentação, ou lê como o mesmo raciocínio se aplica aos outros dois grandes canais nos guias do Airbnb e do Booking.com. Se és uma plataforma SaaS que vai pôr isto à frente dos teus próprios clientes, a parte comercial está em Repull para plataformas, com a versão técnica mais aprofundada nas perguntas e respostas para plataformas SaaS.