gqo5d5DfH242Q5hd · FINALIZADO · ativo · 12 nós
| campo | valor |
|---|---|
| nome | [reserve] Reservas (Stays webhook) |
| id | gqo5d5DfH242Q5hd |
| estado no n8n | ativo |
| empresa | reserve-temporada |
| pilar | Reservas |
| boss | Boss Reservas |
| workplace | FINALIZADO |
| IA | NÃO |
| trigger | Webhook do Stays (POST) — reservation.created / modified / canceled / deleted |
| frequência | a cada evento de reserva no Stays |
| nós · conexões | 12 · 12 |
| tags | audit:revisado · workplace verificado · boss:reservas · tipo:webhook · empresa:reserve · canal:stays · pilar:reservas |
| abrir no n8n | https://n8n.rbrtecnologia.com.br/workflow/gqo5d5DfH242Q5hd |
O dono da RESERVA. Recebe o evento do Stays e mantém o card do hóspede, a disponibilidade do imóvel e os avisos de nascimento e cancelamento. É quem cria o card; todo o resto da esteira trabalha em cima do que ele criou.
Quando o Stays dispara o webhook.
Ao devolver o resumo da operação (ok, reserva, titular, datas, financeiro, stats) — ou ao lançar IMOVEL_NAO_ENCONTRADO se uma reserva ATIVA tem listing que não resolve.
Primeiro nó da esteira. Tudo começa aqui.
| # | nó | tipo | recebe | regra / condição | lê | escreve / efeito | saída | próximo | em falha |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Webhook | webhook | POST do Stays com action e payload | sempre — sem Basic Auth (só x-stays-signature HMAC); a checagem foi removida em 01/07 após LW01J/LW03J caírem em auth_failed | body.action · body.payload | — | payload cru | Config | HTTP 500 ao Stays |
| 2 | Config | set | gatilho do webhook | sempre | — | define token do Notion, ids dos 4 bancos, bases e chaves do WAHA, os 4 templates de mensagem e as flags send_wa_* e modo_validacao | objeto de configuração | Main | — |
| 3 | Main | code | payload + config | o coração, ~15 KB. Guardas em ordem: payload sem _id → shape_invalid · action=deleted → skip · type≠booked e não-cancel → skip · modified <120s após created → race_guard | Notion: Imóveis (por Id Stays), Hóspedes (por ID Stays interno), Disponibilidade, Pricing Intelligence; payload do Stays inteiro | CRIA/ATUALIZA cards de hóspede · marca disponibilidade Reservado/Disponível · arquiva duplicatas · incrementa Reservas Captadas no PI · envia WhatsApp ao hóspede (created) e ao proprietário · POST no Boss Tech em divergência de contagem | {ok, reserva, titular, datas, financeiro, stats} — ou throw | Reserva válida? · IF · Main OK? · Cancelamento hóspede? | lança IMOVEL_NAO_ENCONTRADO só se a reserva estiver ATIVA; em cancelamento registra e segue (fix 17/08) |
| 4 | Reserva válida? | if | saída do Main | boss_notify === true | json.boss_notify | — | passa adiante | Boss Reservas · msg (nova reserva) | — |
| 5 | Boss Reservas · msg (nova reserva) | set | saída do IF | sempre que chegou aqui | reserva, hóspede, empreendimento, cota, datas | monta o evento do Boss | {boss, evento, message} | Boss Reservas · envia (nova reserva) | — |
| 6 | Boss Reservas · envia (nova reserva) | executeWorkflow | evento montado | sempre | — | chama o [Workplace] Telegram Outbound | — | fim | continueOnFail — o aviso não derruba a reserva |
| 7 | IF · Main OK? | if | saída do Main | ok===true OU skip===true | json.ok · json.skip | — | dois ramos | Kuma · push OK + Execution Log · ou Alerta Boss Tech + Execution Log | — |
| 8 | Kuma · push OK | httpRequest | ramo de sucesso | sempre | — | push no monitor Kuma | — | fim | — |
| 9 | HTTP · Execution Log | httpRequest | sucesso OU falha | sempre — os dois ramos alimentam | stats do Main | RPC cockpit_execution_log no Workplace, correlation_id stays-<reserva> | confirmação com boss e pilar resolvidos | fim | onError=continueRegularOutput |
| 10 | HTTP · Alerta Boss Tech (Main falhou) | httpRequest | ramo de falha | Main devolveu ok:false sem skip intencional | error/reason/reserva_id | POST no rt-boss-notify como boss=tech | — | fim | neverError + onError=continueRegularOutput |
| 11 | Cancelamento hóspede? | if | saída do Main | é cancelamento e o hóspede tem telefone | stats/is_cancel/titular.tel | — | passa adiante | WAHA Reserve · Cancelamento Hóspede | — |
| 12 | WAHA Reserve · Cancelamento Hóspede | httpRequest | saída do IF | sempre que chegou aqui | template_hospede_cancel + dados da reserva | WhatsApp ao hóspede pela sessão Reserve | — | fim | — |
| campo | autoridade | quem escreve | quando | quem NÃO sobrescreve |
|---|---|---|---|---|
| nome · e-mail · telefone do hóspede | Stays no created; PÁGINA/Voucher I depois disso | gqo5 só no created | na criação do card | o modified NÃO sobrescreve — regra selada em 14/08, caso NM03J |
| Qtd Hóspedes Contratados | Stays | gqo5, ramo created | na criação | o modified não toca — a gravação vive em _hospedePropsBase, que só o create usa |
| Propriedade · Proprietário | Stays (_idlisting) | gqo5 | created e modified | — |
| Check-in · Check-out | Stays | gqo5 | created e modified | o formulário não altera |
| financeiro (valor, comissão, taxas) | Stays | gqo5 | created e modified, fatiado por diárias em reserva dividida | — |
| disponibilidade | gqo5 | gqo5 | created marca Reservado · canceled marca Disponível | — |
| aspecto | detalhe |
|---|---|
| status escritos | Reserva (no create) · Cancelado (no cancel) |
| transições bloqueadas | modified NUNCA cria card — criar é responsabilidade do created; reserva sem card é a Sentinela que pega (fix 31/07, casos MY01J e MY07J) |
| cancelamento | todos os cards do ID Stays interno vão para Cancelado, independente de imóvel resolver |
| pós-checkout | NÃO SE APLICA — o Stays manda o evento, o workflow não julga data |
| público | identidade | canal | nó | condição | dedup | texto validado | conteúdo | materialidade |
|---|---|---|---|---|---|---|---|---|
| hóspede | Reserve | dentro do Main (bloco 9) | action=created E card recém-criado E tem telefone | idempotência: só se hospedes_create_ok | SIM — 4/4 validadas | boas-vindas + link do formulário + dica de ingressos | material | |
| proprietário | Rental | dentro do Main (bloco 10) | created: todos os donos · modified: só donos NOVOS · canceled: todos | dedup por proprietário único | SIM | nova reserva com empreendimento, cota, datas e código da reserva | material | |
| hóspede | Reserve | WAHA Reserve · Cancelamento Hóspede | é cancelamento e tem telefone | uma vez por evento | SIM | aviso de cancelamento com período e titular | material — mas a POLÍTICA de manter ainda depende do Rafael | |
| Boss Reservas | — | Telegram via Outbound | Boss Reservas · envia | boss_notify=true | Signal Gate no Outbound | n/a | nova reserva | material |
| Boss Tech | — | Telegram via rt-boss-notify | Alerta Boss Tech · e dentro do Main | Main falhou · ou divergência na contagem de hóspedes | n/a | anomalia | material |
| sistema | papel exato |
|---|---|
| Notion | 4 bancos: Hóspedes (cria/atualiza/arquiva), Imóveis (resolve listing), Disponibilidade (Reservado/Disponível), Pricing Intelligence (Reservas Captadas) |
| Stays | origem do evento; nunca é chamado de volta |
| WAHA Reserve | hóspede |
| WAHA Rental | proprietário |
| Workplace | RPC cockpit_execution_log |
| Boss Event | rt-boss-notify e [Workplace] Telegram Outbound |
| Kuma | push no sucesso |
| Supabase Rental | indireto — via o sync a cada 2 min, não por este workflow |
| Cloudflare Worker | NÃO SE APLICA |
| sub-workflows | [Workplace] Telegram Outbound |
SIM — é o workflow que a implementa. childs[] no payload viram N cards, um por cota. O financeiro é fatiado por diárias de cada perna (fix 08/07). O hóspede vê o período GLOBAL; o proprietário, o da sua perna. Pareamento determinístico no modified evita que dois filhos casem com o mesmo card (fix MH01J). Cancelamento arquiva por ID Stays interno + Propriedade, nunca só por ID (fix MA03J).
| data | defeito anterior | consequência | correção | evidência | tocou negócio? |
|---|---|---|---|---|---|
| 13/08 | Template 4 de cancelamento ao hóspede existia e nunca disparava | hóspede não era avisado do cancelamento | 2 nós novos alimentados pela saída do Main — o Code de 15 KB não foi tocado | execuções de cancelamento passaram a disparar | sim |
| 13/08 | sem telemetria; tag status:wip rodando em PROD há 2 meses | execução não registrada | Execution Log nos dois ramos + tag removida | — | não |
| 14/08 | E-mail e Telefone no updateProps do modified | o Stays sobrescrevia com o alias da OTA e apagava o telefone gravado pelo formulário (caso NM03J) | os dois campos saíram do updateProps; stats registra contato_hospede_no_modified | exec 867626 em diante trazem 'nao_tocado' | sim |
| 17/08 | Qtd Hóspedes Contratados não era gravada | sem ela não há base para calcular hóspedes adicionais | soma adults+children+infants no created, dentro de _hospedePropsBase (que só o create usa) | cadeia provada até o Supabase com a NM03J | sim |
| 17/08 | cancelamento de reserva multi-unit não liberava estoque | o cancel chega SEM childs, o listing raiz é o PAI/FAKE e o código o lia como single-unit. HA336I ficou Reservado 17–19/09 por reserva cancelada | no cancelamento o imóvel vem dos CARDS, não do payload; PAI não resolvido em cancel não lança | caso OU06J, execuções 866151 e 881348 | sim |
EXECUÇÃO REAL
| item | valor |
|---|---|
| execução | 881346 · 17/08 16:17 |
| reserva | OQ11J · reservation.modified · childs=1 |
| resultado | sucesso · card atualizado · contato do hóspede não tocado |
| efeito verificado | cockpit_execution_log id=476 · boss='Boss Reservas' · pilar='Reservas' · uses_ai=false |
| prova do guard de contato | execuções 867626 (15/08) e 870021 registram contato_hospede_no_modified='nao_tocado' |
| prova da contagem | NM03J: Notion 6 → Shape qtd_hospedes 6 → RPC hospedes_upserted 1 |
| item | camada | estado |
|---|---|---|
| Kuma sem acesso admin | infraestrutura do Pilar | BLOQUEIO EXTERNO |
| 3 segredos literais no Config | hardening transversal | PENDENTE |
| 3 linhas de estoque da OU06J ainda Reservado | saneamento de dados | PENDENTE — dano legado, o fluxo já não produz mais |
| cards com contato destruído antes de 14/08 | saneamento de dados | NÃO MAPEADO — sem varredura retroativa |
| política da mensagem de cancelamento ao hóspede | decisão do Rafael | PENDENTE — foi restauração de template existente, não regra canônica |
FINALIZADO — Faz o que promete, com guardas datadas para cada caso real que quebrou, e os dois P1 encontrados na auditoria foram corrigidos e provados.
Fonte: estrutura-workflows.json (definição viva do n8n PROD, sanitizada) + fichas-detalhe.json · gerado por scripts/gerar-fichas.py. Nenhum token, senha ou PII nesta página.