1. Visão geral do ecossistema

No cenário de distribuição hoteleira, a comunicação ocorre em camadas bem definidas:

Canal (OTA / Motor de Reservas) → Channel Manager (Desbravador) → PMS

Cada sistema possui responsabilidades específicas e se comunica por meio de requests (envios) e responses (retornos), normalmente em formato JSON.

2. Quem são os canais (origem da reserva)

Exemplos de canais integrados:

• Booking.com

• Expedia

• Omnibees

• Decolar

• PM WEB (Let’s Book)

• Motor de Reservas do site do hotel

Esses sistemas são responsáveis por gerar a reserva após a ação do hóspede.

3. Exemplo completo — Criação de reserva

3.1 Canal → Channel (Request de envio)

Quando o hóspede conclui a reserva no canal, o canal envia um request ao Channel Manager contendo os dados da reserva.

Exemplo de JSON de envio do Canal para o Channel:

{
  "action": "CreateReservation",
  "channel": "PMWEB",
  "locator": "PMW123456",
  "hotelId": 4572,
  "checkin": "2026-02-10",
  "checkout": "2026-02-12",
  "guests": {
    "adults": 2,
    "children": 0
  },
  "roomType": "STD",
  "ratePlan": "BAR",
  "amount": 980.00,
  "currency": "BRL"
}

📌 Neste momento:

• O Canal envia

• O Channel recebe e valida

• Nenhuma ação no PMS ocorre ainda

3.2 Channel → Canal (Response de retorno)

Após receber o request, o Channel retorna um response confirmando o recebimento da reserva.

Exemplo de JSON de retorno do Channel para o Canal:

{
  "status": "SUCCESS",
  "message": "Reserva recebida com sucesso",
  "channelReservationId": "1861ID17461426"
}

📌 Aqui:

• O Canal entende que a reserva foi aceita

• A responsabilidade do Canal se encerra

4. Channel → PMS (Request disponibilizado)

O Channel não envia ativamente reservas ao PMS.
O PMS é quem consulta o Channel para buscar novas reservas.

Quando isso ocorre, o Channel disponibiliza o request da reserva.

Exemplo de JSON disponibilizado pelo Channel para consumo do PMS:

{
  "action": "NewReservation",
  "origin": "PMWEB",
  "channelReservationId": "1861ID17461426",
  "hotelId": 4572,
  "stay": {
    "checkin": "2026-02-10",
    "checkout": "2026-02-12"
  },
  "guests": {
    "adults": 2,
    "children": 0
  },
  "financial": {
    "dailyRate": 490.00,
    "totalAmount": 980.00,
    "currency": "BRL"
  }
}

📌 Importante:

• Esse request só existe se o PMS consultar

• O Channel apenas disponibiliza a informação

5. PMS → Channel (Response de processamento)

Após consumir a reserva, o PMS processa internamente e retorna um response ao Channel.

5.1 Exemplo de sucesso

{
  "status": "SUCCESS",
  "pmsReservationNumber": "458721",
  "message": "Reserva criada com sucesso no PMS"
}

5.2 Exemplo de erro

{
  "status": "ERROR",
  "errorCode": "RATE_PLAN_NOT_FOUND",
  "message": "Tarifa não cadastrada no PMS"
}

📌 O Channel:

• Apenas registra o retorno

• Não interpreta regras internas do PMS

• Não corrige erros de cadastro

6. Onde normalmente ocorrem as falhas

Cenário 1 — PMS não consulta

• Request do Canal existe

• Channel recebeu

• ❌ Não há response do PMS

➡️ Problema no PMS

Cenário 2 — PMS consulta e rejeita

• Request existe

• Response com erro

➡️ Problema de regra, tarifa ou mapeamento no PMS

Cenário 3 — Erro atribuído incorretamente ao Channel

• Request recebido corretamente

• PMS não retorna processamento

• Ticket indica “erro de integração”

➡️ Diagnóstico incorreto

7. Por que solicitar os JSONs no ticket

Para análise técnica correta, é obrigatório solicitar:

• JSON do Canal → Channel

• JSON do Channel → PMS

• JSON do PMS → Channel (response)

📌 Sem esses três pontos, não é possível identificar:

• Onde o fluxo parou

• Qual sistema falhou

• Se o erro é técnico ou de regra de negócio

8. Resumo rápido para técnicos

• Canal envia

• Channel recebe e disponibiliza

• PMS consulta, processa e retorna

• Channel não força processamento

• Sem response do PMS, o fluxo está incompleto

9. Conclusão

Toda análise de integração deve sempre responder:

Quem enviou?
Quem consumiu?
Quem retornou?

A ausência de qualquer uma dessas respostas inviabiliza a conclusão técnica.