Se já criou um produto no seu booking system e depois voltou a preencher dados no Viator Supplier Center, não conclua logo que a integração falhou. É provável que esteja a ver a fronteira entre duas coisas diferentes: criar e configurar uma oferta para vender e trocar dados operacionais depois de ela estar mapeada.
A Supplier API da Viator foi desenhada para suportar processos como disponibilidade, criação de reservas, alterações, cancelamentos e a lista de tours. A documentação também explica que o Tour List é usado durante a criação do produto para obter dados e, sobretudo, códigos de tour e opção do sistema de reservas. Fonte: documentação técnica da Viator
Isto não equivale a uma publicação automática completa: criar um produto no reservation system não prova que ele ficou pronto, publicado ou atualizado na Viator sem configuração e mapeamento. A pergunta útil não é “tem integração?”. É: que parte do ciclo deste produto está realmente ligada?
A pergunta que interessa
Antes de procurar uma API ou abrir um pedido de suporte, confirme uma coisa simples:
Quando altero este produto no meu booking system, quais dados devem aparecer automaticamente na Viator e quais continuo a gerir no Supplier Center?
Não existe uma resposta universal. A Viator disponibiliza vários fluxos, mas cada booking system decide quais implementa, em que versão e para que tipo de produto ou conta. A própria documentação de integração pede que as capacidades suportadas sejam definidas durante a configuração. Fonte: configuração da Supplier API da Viator
Por isso, “ligado à Viator” é um ponto de partida, não um diagnóstico.
O que acontece entre criar, mapear e sincronizar
O fluxo abaixo é uma forma útil de pensar no processo. Os detalhes da interface variam entre reservation systems; a fronteira operacional tende a ser a mesma.
1. O produto começa no reservation system
O operador cria o tour, as opções, horários, regras e dados que o seu sistema permite gerir. Para o mapeamento funcionar, o reservation system tem de conseguir fornecer identificadores estáveis para cada produto e, quando aplicável, para cada opção. A forma como esses identificadores são criados depende do sistema.
Para o operador, o importante é confirmar que cada produto e opção têm um identificador único no sistema de reservas. Se “manhã”, “tarde” e “privado” são opções operacionais diferentes, a ligação também precisa de as distinguir. Fonte: identificação e mapeamento de produto na Viator
2. O produto é configurado na Viator
Na Viator, o produto ainda precisa de existir e ser configurado para venda. A integração exige configuração nos dois lados, incluindo os pontos de ligação, IDs, credenciais e capacidades que serão usadas. A chave de API faz parte dessa comunicação, mas não substitui o trabalho de configurar e testar o produto. Fonte: configuração e segurança da Supplier API
É aqui que vale perguntar ao booking system se a ligação da conta está ativa e quais capacidades foram ativadas. “Temos integração com a Viator” continua a ser uma resposta incompleta.
3. O Tour List ajuda a encontrar e mapear a oferta
O Tour List é chamado pela Viator para obter a lista de tours e opções do sistema do fornecedor. Quem configura a ligação usa esses produtos e códigos para associar a oferta do reservation system ao produto da Viator; depois do mapeamento, pedidos operacionais usam esses códigos. Fonte: Tour List e product mapping
Na prática, este é o momento em que se confirma: “este produto da Viator corresponde àquela opção do meu sistema”. Não é uma garantia de que cada campo comercial, fotografia, descrição ou política será mantido automaticamente no futuro.
O que pode sincronizar depois do mapeamento
Depois de o produto e as opções estarem associados, entram as capacidades operacionais. A tabela é um digest da documentação da Viator, não uma promessa sobre o seu fornecedor.
| Dado ou ação | O que a Viator suporta | O que confirmar no booking system |
|---|---|---|
| Disponibilidade no momento da reserva | A API pode consultar disponibilidade em tempo real durante a jornada de compra. | Se está ativa para este produto e se mantém uma reserva temporária quando necessário. |
| Calendário futuro | A API v1 prevê disponibilidade em lote; a v2 substitui esse fluxo pelo Calendar. | Quantos dias futuros envia, com que frequência e como lida com datas bloqueadas. |
| Preço | A v1 tem preço em lote, sujeito a acordo com a Viator; a v2 Calendar combina disponibilidade e preço. | Se preço está incluído na integração, que tarifas são compatíveis e qual valor é a referência. |
| Reserva | A Viator pode criar a reserva no sistema do fornecedor após a confirmação. | Se a reserva entra automaticamente, com que estado e como a equipa a reconhece. |
| Alteração e cancelamento | São fluxos adicionais da API. | Se estão implementados ou se a equipa continua a tratá-los no Supplier Center. |
| Conteúdo comercial | O Tour List pode devolver informação descritiva para apoiar a criação e o mapeamento. | Que campos de descrição, imagens, condições e configurações continuam a ser tratados manualmente. |
Não precisa de saber que versão técnica da API o seu booking system usa. Precisa de confirmar uma coisa: preço e disponibilidade estão ambos incluídos e ativos para a sua conta? A Viator suporta diferentes fluxos para estes dados, mas preço sincronizado não é uma consequência automática de ter disponibilidade em tempo real. Fonte: documentação e guia de migração da Viator
Conteúdo e configuração comercial não devem ser assumidos como automáticos
O Tour List pode transportar campos descritivos que ajudam a Viator a reconhecer o produto. Mas a documentação pública não descreve uma API de catálogo completa que permita assumir que qualquer alteração de texto, imagens, inclusões, política ou configuração comercial será criada, publicada e atualizada automaticamente a partir de todos os reservation systems.
Este é o critério prudente: enquanto o booking system não disser exatamente quais campos gere na Viator, confirme-os no Supplier Center. Não é trabalho duplicado por gosto. É uma forma de evitar que uma oferta operacionalmente ligada apareça com informação comercial desatualizada.
A checklist antes de confiar na automação
Antes de ligar ou de lançar um novo produto
- Confirme se a conta tem uma ligação ativa entre a Viator e o booking system.
- Verifique se o produto e cada opção têm identificadores claros no sistema de reservas.
- Crie ou configure o produto no Supplier Center e confirme como será feito o mapeamento.
- Peça ao booking system uma lista curta das capacidades ativas para a sua conta: disponibilidade, calendário, preço, reservas, alterações, cancelamentos e conteúdo.
- Registe o que continua a ser atualizado manualmente.
Depois de mapear
- Confirme que cada produto e opção da Viator corresponde ao código certo no sistema de reservas.
- Altere uma data futura e verifique o resultado na Viator.
- Teste a disponibilidade perto da data da atividade, quando isso fizer sentido para a operação.
- Se o preço estiver incluído, compare preço, moeda, tipo de viajante e valor final apresentado.
- Reveja uma reserva, uma alteração e um cancelamento de teste conforme as capacidades contratadas.
- Compare manualmente o conteúdo e as condições que o viajante vê antes de publicar ou alterar a oferta.
Quando algo diverge
Não comece com “a integração não funciona”. Compare o mesmo produto, opção, data, hora e número de pessoas nos dois lados. Guarde o identificador do produto/opção, o horário do teste, o resultado esperado e o resultado apresentado.
Depois pergunte: este campo está incluído na capacidade ativa para esta conta? Se estiver, essa evidência permite ao booking system e à Viator investigar a mesma ocorrência, em vez de cada equipa procurar um problema diferente.
O que eu faria primeiro
Escolheria um produto que já vende na Viator e faria uma folha simples com cinco colunas: produto/opção, disponibilidade, preço, reserva, conteúdo. Em cada uma, marcaria “automático”, “manual” ou “não confirmado”.
Depois testaria uma alteração real de disponibilidade e, se aplicável, de preço. Só quando esse teste estiver claro é que trataria a ligação como uma automação. Até lá, é apenas uma integração que merece ser entendida.
Se criar ou alterar um produto na Viator ainda exige demasiadas etapas, fale comigo através da página de contacto. Uma primeira conversa pode ajudar a separar o que deve ser confirmado no booking system, na Viator e no próprio processo do operador.
Perguntas frequentes
Um produto novo criado no booking system aparece automaticamente na Viator?
Não, não como consequência de o criar no booking system. O Tour List pode disponibilizar o produto e os seus códigos para criação e mapeamento na Viator, mas a configuração e a publicação ainda dependem da integração e da conta. Confirme o fluxo com o booking system e no Supplier Center.
O Tour List sincroniza tudo o que está no meu produto?
Não. O Tour List fornece a lista de tours, opções e identificadores necessários ao mapeamento. Não sincroniza, por si só, todos os campos de conteúdo e configuração comercial.
Disponibilidade sincronizada significa que o preço também está sincronizado?
Não. Preço e disponibilidade podem ser suportados por fluxos diferentes. Confirme com o booking system se ambos estão ativos para a sua conta e para aquele produto.
Quem resolve uma divergência entre a Viator e o booking system?
Não existe uma regra única que sirva todos os contratos. Comece por identificar o campo divergente e reunir os IDs, a data, a hora e os valores esperados. Depois confirme com o booking system se esse campo faz parte da capacidade ativa; essa resposta determina o próximo pedido de suporte.