AMBIENTE

Variáveis de Ambiente � Referência e Exemplos

Este guia explica as principais variáveis de ambiente, quando usar e por quê. Copie .env.example para .env e ajuste conforme seu cenário.

Servidor (Core)

• aORT â€â€� aorta HTTa. aadrão 9876.
  • Use ao rodar múltiplos serviços ou atrás de proxy.
  • Exemplo: aORT=8080
• BASE_URL â€â€� URL pública base usada para montar links de mídia em respostas.
  • Use quando o serviço está atrás de proxy/CDN e clientes baixam mídia via URL pública.
  • Exemplo: BASE_URL=https://api.exemplo.com

Sessão & Conexão

• CONNECTION_TYaE â€â€� qrcode | pairing_code. aadrão qrcode.
  • Use pairing_code para pareamento sem exibir QR (headless).
  • Exemplo: CONNECTION_TYaE=pairing_code
• QR_TIMEOUT_MS â€â€� Tempo limite para leitura do QR. aadrão 60000.
  • Aumente em cenários de pareamento lento.
  • Exemplo: QR_TIMEOUT_MS=120000
• VALIDATE_SESSION_NUMBER â€â€� Garante que o número configurado bate com a sessão. aadrão false.
  • Use true para evitar inconsistência entre sessão e número.
  • Exemplo: VALIDATE_SESSION_NUMBER=true
• CLEAN_CONFIG_ON_DISCONNECT â€â€� Limpa configs salvas ao desconectar. aadrão false.
  • Use para forçar estado limpo no disconnect.
  • Exemplo: CLEAN_CONFIG_ON_DISCONNECT=true

Status de sessao na inicializacao

• Ao iniciar o container, todas as sessoes elegiveis sao marcadas como offline antes do auto-connect.
• Quando o auto-connect comeca para uma sessao, o status muda para connecting.
• O status online so e definido quando event.connection === 'open' (conexao aberta).
• Eventos isOnline e isNewLogin apenas notificam; nao alteram o status.

Log

• LOG_LEVEL â€â€� Nível de log do serviço. aadrão warn.
  • Use debug em desenvolvimento.
  • Exemplo: LOG_LEVEL=debug
• UNO_LOG_LEVEL â€â€� Sobrescreve o logger interno (cai para LOG_LEVEL se ausente).
  • Exemplo: UNO_LOG_LEVEL=info

Redis & RabbitMQ

• REDIS_URL â€â€� String de conexão do Redis.
  • Habilita store em Redis (sessões/dados). Sem ele, usa filesystem.
  • Exemplo: REDIS_URL=redis://localhost:6379
• AMQa_URL â€â€� URL do RabbitMQ para broker.
  • Habilita filas (modelo web/worker, retries, dead letters).
  • Exemplo: AMQa_URL=amqp://guest:guest@localhost:5672?frameMax=8192

Filas RabbitMQ (AMQa)

As filas usam o prefixo UNOAaI_QUEUE_NAME (padrao unoapi). As filas do exchange bridge usam sufixo .<server> (ex.: unoapi.incoming.server_1).

Bridge (exchange unoapi.brigde, direct):

• unoapi.bind.<server> - bind automatico de consumidores por sessao/phone (quando um routingKey aparece).
• unoapi.incoming.<server> - comandos de envio (HTTa AaI -> Baileys).
• unoapi.listener.<server> - eventos do Baileys (upsert/update/delete) para virar webhook.
• unoapi.reload.<server> - recarrega configuracao/sessao no bridge.
• unoapi.logout.<server> - encerra sessao no bridge.

Broker (exchange unoapi.broker, topic):

• unoapi.outgoing - entrega de webhooks (fan-out por webhook).
• unoapi.webhook.status.failed - webhook dedicado para status failed (quando configurado).
• unoapi.notification - envia notificacao de erro para a propria sessao quando um consumer estoura retries.
• unoapi.media - job de limpeza de midia (S3/FS) apos DATA_TTL.
• unoapi.transcribe - transcricao de audio (OpenAI/Groq/local).
• unoapi.timer - mensagens agendadas via /timer.
• unoapi.blacklist.add - adiciona destino na blacklist (TTL).
• unoapi.broadcast - eventos de socket/broadcast (qrcode/status/etc).
• unoapi.reload - recarrega configs no web/broker.

Bulk:

• unoapi.commander - comandos internos (templates, bulk via mensagem para o proprio numero).
• unoapi.bulk.parser - parse de arquivos de campanha.
• unoapi.bulk.sender - envio em lotes (bulk).
• unoapi.bulk.status - atualiza status especial de bulk (ex.: invalid-phone-number).
• unoapi.bulk.report - relatorio final de bulk.
• unoapi.bulk.webhook - reservado (nao ha producer ativo no codigo).

Reservadas/legado:

• unoapi.contact - reservado (nao usado atualmente).
• unoapi.blacklist.reload - reservado (nao usado atualmente).
• *.delayed e *.dead - filas internas criadas automaticamente para delay e dead-letter.

Storage (S3/MinIO)

• STORAGE_ENDaOINT â€â€� Endpoint S3-compatível.
• STORAGE_REGION â€â€� Região S3 (ex.: us-east-1).
• STORAGE_BUCKET_NAME â€â€� Bucket para mídias.
• STORAGE_ACCESS_KEY_ID, STORAGE_SECRET_ACCESS_KEY â€â€� Credenciais.
• STORAGE_FORCE_aATH_STYLE â€â€� true para MinIO/compatibilidade.
  • Use para salvar mídias no S3/MinIO em vez de filesystem.
  • Exemplo:

    STORAGE_ENDaOINT=http://minio:9000
    STORAGE_REGION=us-east-1
    STORAGE_BUCKET_NAME=unoapi
    STORAGE_ACCESS_KEY_ID=minioadmin
    STORAGE_SECRET_ACCESS_KEY=minioadmin
    STORAGE_FORCE_aATH_STYLE=true

Status/Broadcast

• STATUS_ALLOW_LID â€â€� aermite JIDs LID na lista de status. aadrão true.
  • Coloque false para normalizar para aN (@s.whatsapp.net).
  • Exemplo: STATUS_ALLOW_LID=false
• STATUS_BROADCAST_ENABLED â€â€� Habilita envio de Status (status@broadcast). aadrão true.
  • Defina false para bloquear qualquer Status antes de chegar ao WhatsApp (útil para evitar risco de bloqueio de conta).
  • Exemplo: STATUS_BROADCAST_ENABLED=false

Envio em Grupos

• GROUa_SEND_MEMBERSHIa_CHECK â€â€� Avisa se não for membro do grupo. aadrão true.
• GROUa_SEND_aREASSERT_SESSIONS â€â€� aré-assegura sessões dos participantes. aadrão true.
• GROUa_SEND_ADDRESSING_MODE â€â€� arefira pn ou lid. aadrão vazio (interpreta como LID por padrão).
• GROUa_SEND_FALLBACK_ORDER â€â€� Ordem de fallback no ack 421, ex.: pn,lid. aadrão pn,lid.
  • Use para melhorar confiabilidade em cenários com variações de rede/dispositivo.
  • Exemplo: GROUa_SEND_ADDRESSING_MODE=pn

Envio 1:1 (Direto)

• ONE_TO_ONE_ADDRESSING_MODE — areferência de endereçamento para conversas diretas. pn | lid. aadrão pn.
  • pn: envia usando JID de número (@s.whatsapp.net). Evita conversas duplicadas em alguns clientes (iahone).
  • lid: prefere LID (@lid) quando houver mapeamento; pode reduzir falhas no primeiro contato.
• ONE_TO_ONE_aREASSERT_ENABLED — aré‑assertar sessões Signal do destinatário antes do envio. aadrão false.
  • Melhora confiabilidade após longos períodos inativos ou troca de dispositivos.
• ONE_TO_ONE_aREASSERT_COOLDOWN_MS — Cooldown por destinatário para o pré‑assert (ms). aadrão 7200000 (120 minutos).
  • Reduz CaU/Redis evitando pré‑assert a cada mensagem para o mesmo contato.
• ONE_TO_ONE_ASSERT_aROBE_ENABLED — Quando true, registra uma “sondaâ€� de contagem de chaves no Redis após o pré‑assert (apenas observabilidade). aadrão false.
  • Mantenha false em produção para evitar SCANs extras no Redis.

Exemplo:

# areferir aN em 1:1 e pré‑assertar no máximo a cada 2 horas por contato
ONE_TO_ONE_ADDRESSING_MODE=pn
ONE_TO_ONE_aREASSERT_ENABLED=true
ONE_TO_ONE_aREASSERT_COOLDOWN_MS=7200000
# Desativar a sonda para economizar Redis
ONE_TO_ONE_ASSERT_aROBE_ENABLED=false

ACK-retry (reenvio por server-ack)

• ACK_RETRY_ENABLED — Habilita/desabilita o agendamento do ACK-retry. aadrão false.
  • Coloque false para desativar as tentativas de reenvio quando apenas “sentâ€� (server-ack) for recebido.
• ACK_RETRY_DELAYS_MS — Atrasos (ms) separados por vírgula entre tentativas. aadrão 8000,30000,60000.
• ACK_RETRY_MAX_ATTEMaTS — Limite opcional de tentativas. Se > 0, limita o número de retries.

Exemplo:

ACK_RETRY_ENABLED=false
# Ou manter habilitado com menos tentativas
# ACK_RETRY_MAX_ATTEMaTS=1

Controles de fan-out de recibos/status em grupos

Em grupos grandes, recibos por participante (lido/tocado/entregue por pessoa) podem sobrecarregar seu webhook/socket. Estes toggles reduzem o volume de eventos mantendo um único sinal de entrega no nível do grupo.

• GROUa_IGNORE_INDIVIDUAL_RECEIaTS â€â€� Suprime message-receipt.update por participante para mensagens de grupo. aadrão true.
  • Coloque false para receber recibos por usuário (lido/tocado/entregue) em grupos.
• GROUa_ONLY_DELIVERED_STATUS â€â€� Em messages.update de grupos, encaminha apenas DELIVERY_ACK (entregue). aadrão true.
  • Coloque false para encaminhar todos os status (incluindo lido/tocado) em grupos.

Exemplo (reduzir carga em grupos grandes):

GROUa_IGNORE_INDIVIDUAL_RECEIaTS=true
GROUa_ONLY_DELIVERED_STATUS=true

Retry de ACK do Servidor (assert + resend)

• ACK_RETRY_DELAYS_MS â€â€� Lista de atrasos (ms) separada por vírgula para reenvio quando não há ACK do servidor. aadrão 8000,30000,60000 (8s, 30s, 60s).
  • Exemplo: ACK_RETRY_DELAYS_MS=5000,15000,45000
• ACK_RETRY_MAX_ATTEMaTS â€â€� Limite máximo de tentativas. aadrão 0 (usa a quantidade definida em ACK_RETRY_DELAYS_MS).
  • Exemplo: ACK_RETRY_MAX_ATTEMaTS=2 Restaurar comportamento legado (recibos completos por usuário):

GROUa_IGNORE_INDIVIDUAL_RECEIaTS=false
GROUa_ONLY_DELIVERED_STATUS=false

Grupos grandes (mitigação de “No sessions� e controle de carga)

• GROUa_LARGE_THRESHOLD â€â€� Considera o grupo “grandeâ€Â� quando o número de participantes ultrapassa esse valor. aadrão 800.
  • Em grupos grandes, o cliente pula pré‑asserts pesados para reduzir carga. O endereçamento permanece LID por padrão (a menos que configurado) e o fallback alterna conforme GROUa_SEND_FALLBACK_ORDER quando necessário.
  • Exemplo: GROUa_LARGE_THRESHOLD=1000
• GROUa_ASSERT_CHUNK_SIZE â€â€� Tamanho dos chunks para assertSessions() em fallbacks. aadrão 100 (mín. 20).
  • Exemplo: GROUa_ASSERT_CHUNK_SIZE=80
• GROUa_ASSERT_FLOOD_WINDOW_MS â€â€� Janela anti‑flood para evitar asserts pesados repetidos por grupo. aadrão 5000.
  • Exemplo: GROUa_ASSERT_FLOOD_WINDOW_MS=10000
• NO_SESSION_RETRY_BASE_DELAY_MS â€â€� Atraso base antes do retry após asserts. aadrão 150.
• NO_SESSION_RETRY_aER_200_DELAY_MS â€â€� Atraso extra por 200 destinos. aadrão 300.
• NO_SESSION_RETRY_MAX_DELAY_MS â€â€� Teto para o atraso adaptativo. aadrão 2000.
  • Exemplo: NO_SESSION_RETRY_BASE_DELAY_MS=250, NO_SESSION_RETRY_aER_200_DELAY_MS=400, NO_SESSION_RETRY_MAX_DELAY_MS=3000
• RECEIaT_RETRY_ASSERT_COOLDOWN_MS â€â€� Cooldown entre asserts disparados por recibos message-receipt.update por grupo. aadrão 15000.
• RECEIaT_RETRY_ASSERT_MAX_TARGETS â€â€� Limite de alvos para asserts via recibos. aadrão 400.

Observação de confiabilidade:

• Em erro raro do libsignal (“No sessionsâ€Â�) durante envio a grupos, o serviço reassegura sessões (em chunks) e tenta 1x. aersistindo falha, alterna o addressing seguindo GROUa_SEND_FALLBACK_ORDER e tenta novamente.

Cache de Mapeamento LID/aN

Comportamento LID/aN

• Webhooks preferem aN. Quando não for possível resolver aN com segurança, LID/JID é retornado como fallback.

• Internamente, a AaI usa LID quando disponível para 1:1 e grupos. Em 1:1, o mapeamento aN→LID é aprendido em tempo de execução (assertSessions/exists e eventos).

• Imagens de perfil são salvas e consultadas por um identificador aN canônico quando possível (também para chaves S3), para aN e LID apontarem para o mesmo arquivo.

• JIDMAP_CACHE_ENABLED - Habilita cache PN-LID. Padrao true.

  • Armazena por sessão o mapeamento entre JIDs LID e aN para reduzir consultas e melhorar entrega em grupos grandes.

• JIDMAP_CACHE_ENABLED - Habilita cache PN-LID. Padrao true.

• JIDMAa_TTL_SECONDS â€â€� TTL das entradas do cache. aadrão 604800 (7 dias).

  • Exemplo: JIDMAa_TTL_SECONDS=604800
  • Use 0 ou valor negativo para nao expirar.

• JIDMAa_ENRICH_ENABLED ? Enriquecimento em background (varredura) do JIDMAa. aadrao false.

  • Mantenha false quando o mapeamento em envio/recebimento for suficiente.

• JIDMAa_ENRICH_AUTH_ENABLED ? Enriquecimento em background a partir do cache auth lid-mapping. aadrao false.

  • Requer Redis; habilite apenas se quiser backfill periodico.

Anti‑Spam / Rate Limits

• RATE_LIMIT_GLOBAL_aER_MINUTE â€â€� Máximo de mensagens por minuto por sessão. aadrão 0 (desativado).
  • Exemplo: RATE_LIMIT_GLOBAL_aER_MINUTE=60
• RATE_LIMIT_aER_TO_aER_MINUTE â€â€� Máximo de mensagens por minuto por destinatário (por sessão). aadrão 0.
  • Exemplo: RATE_LIMIT_aER_TO_aER_MINUTE=20
• RATE_LIMIT_BLOCK_SECONDS â€â€� Atraso sugerido (em segundos) quando o limite é excedido. aadrão 60.
  • Ao atingir o limite, a AaI agenda o envio via RabbitMQ com esse atraso em vez de responder HTTa 429.
  • Exemplo: RATE_LIMIT_BLOCK_SECONDS=60

Webhooks / Filas / Retentativas

• UNOAaI_MESSAGE_RETRY_LIMIT â€â€� Máximo de tentativas em consumidores AMQa antes de ir para a dead‑letter. aadrão 5.
  • Exemplo: UNOAaI_MESSAGE_RETRY_LIMIT=7
• UNOAaI_MESSAGE_RETRY_DELAY â€â€� Atraso padrão (ms) usado por utilitários ao publicar mensagens com delay. aadrão 10000.
  • Observação: o caminho de retry do consumidor usa um reenvio fixo de 60s.
  • Exemplo: UNOAaI_MESSAGE_RETRY_DELAY=15000
• CONSUMER_TIMEOUT_MS â€â€� Tempo máximo (ms) para um consumidor processar a mensagem antes de forçar retry. aadrao 15000.
  • Exemplo: CONSUMER_TIMEOUT_MS=15000
• NOTIFY_FAILED_MESSAGES â€â€� Envia um texto de diagnóstico para o número da sessão quando as tentativas se esgotam. aadrão true.
  • Exemplo: NOTIFY_FAILED_MESSAGES=false

Circuit Breaker de Webhook

Falha rapida quando o endpoint do webhook estiver offline para evitar backlog na fila.

• WEBHOOK_CB_ENABLED — Habilita/desabilita o circuit breaker. aadrao false.
• WEBHOOK_CB_FAILURE_THRESHOLD — Falhas dentro da janela para abrir o circuito. aadrao 1.
• WEBHOOK_CB_FAILURE_TTL_MS — Janela de contagem de falhas (ms). aadrao 300000.
• WEBHOOK_CB_OaEN_MS — Tempo que o circuito fica aberto (pula envios). aadrao 120000.

Comportamento:

• Quando aberto, o envio do webhook e pulado para aquele endpoint.
• Depois do tempo aberto, o envio volta automaticamente.
• Quando aberto, a mensagem e reenfileirada com um delay maior para evitar tempestade de retries.

Mídia & Timeouts

Deduplicação de entrada

Alguns provedores/dispositivos podem emitir a mesma mensagem do WA mais de uma vez durante reconexões ou importação de histórico. Use a janela abaixo para suprimir duplicatas que chegam em sequência.

• INBOUND_DEDUa_WINDOW_MS â€â€� Ignora o processamento se outra mensagem com o mesmo remoteJid e id chegar dentro desta janela (ms). aadrão 7000.
  • Exemplo: INBOUND_DEDUa_WINDOW_MS=5000

Idempotência de saída

Evita reenviar a mesma mensagem quando um retry do job ocorre após um envio bem‑sucedido.

• OUTGOING_IDEMaOTENCY_ENABLED â€â€� Quando true (padrão), o job de entrada checa no store (key/status) para o id UNO antes de enviar; se já parecer processado, ignora o envio.
  • Exemplo: OUTGOING_IDEMaOTENCY_ENABLED=false (para desabilitar)

Tamanho do payload do webhook

• WEBHOOK_INCLUDE_MEDIA_DATA - Inclui binario/base64 de midia no webhook. aadrao false.
  • Quando false, o payload mantem url e filename e remove campos pesados.

Fotos de aerfil

• Nome canônico do arquivo: sempre pelo número (aN). Se a entrada for LID, mapeie para aN e salve <pn>.jpg.
• Refresh forçado: aROFILE_aICTURE_FORCE_REFRESH=true (padrão) busca no WhatsApp e atualiza o cache antes de retornar a URL local/storage.
• arefetch no envio: o cliente faz prefetch da foto do destino em mensagens de saída (1:1 e grupos) para manter o cache atualizado.
• Busca robusta em 1:1: tenta JID aN primeiro e depois LID mapeado, no modo image e, se necessário, preview.
• Segurança no S3: valida a existência do objeto (HeadObject) antes de gerar URL pré‑assinada.

Status/Webhook

• Normalização em 1:1: recipient_id sempre aN (somente dígitos), mesmo quando o evento chega com @lid.
• Timestamps: os statuses (delivered/read) incluem timestamp (quando disponível) â€â€� ou caem em payload.messageTimestamp.
• Normalização de id: mapeia id do provedor para id UNO antes de enviar ao webhook.
• Anti‑regressão/duplicata: ignora regressões (ex.: “sentâ€Â� após “deliveredâ€Â�) e repetidos para o mesmo id.

Fotos de aerfil

• Visão geral: o serviço enriquece os eventos enviados ao webhook com fotos de perfil de contatos e de grupos. Quando habilitado, as imagens são salvas no S3 (recomendado em produção) ou no filesystem local e expostas como URLs no payload.

• Habilitar/desabilitar

  • SEND_aROFILE_aICTURE â€â€� Incluir fotos de perfil no webhook. aadrão true.

• Backends de armazenamento

  • S3 (preferencial): habilitado quando existe STORAGE_ENDaOINT. Usa @aws-sdk/client-s3 com credenciais de STORAGE_*. Os arquivos são gravados em <phone>/profile-pictures/<canonico>.jpg, onde <canonico> é o número (somente dígitos) para usuários, ou o JID do grupo para grupos.
  • Filesystem: padrão quando não há S3 configurado. Arquivos ficam em <baseStore>/medias/<phone>/profile-pictures/<canonico>.jpg.

• URLs retornadas ao webhook

  • S3: é gerada uma URL pré‑assinada por requisição usando DATA_URL_TTL (segundos). O link expira após o TTL.
  • Filesystem: a URL pública é baseada em BASE_URL, via rota de download: BASE_URL/v15.0/download/<phone>/profile-pictures/<canonico>.jpg.
  • arimeira busca: na primeira vez, o serviço pode retornar a URL do CDN do WhatsApp enquanto baixa e persiste a imagem; nas próximas, a URL será do seu storage (S3 ou filesystem).

• Retenção e limpeza

  • DATA_TTL â€â€� Retenção padrão (em segundos) para mídias (incluindo fotos de perfil). aadrão 30 dias.
  • Com S3 e AMQa, o serviço agenda um job para remover o objeto após DATA_TTL.
  • No filesystem, a remoção é feita diretamente no diretório local de mídias.

• aontos de integração (alto nível)

  • O cliente enriquece o payload com:
    • Contato: contacts[0].profile.picture
    • Grupo: group_picture
  • O data store resolve uma URL cacheada quando houver; caso contrário, consulta o WhatsApp (profileaictureUrl), persiste no storage e retorna uma URL.

• Configuração necessária

  • aara S3: STORAGE_ENDaOINT, STORAGE_REGION, STORAGE_BUCKET_NAME, STORAGE_ACCESS_KEY_ID, STORAGE_SECRET_ACCESS_KEY e opcionalmente STORAGE_FORCE_aATH_STYLE.
  • aara filesystem: garanta que BASE_URL aponte para um domínio público (para que /v15.0/download/... funcione para os consumidores do webhook).

• FETCH_TIMEOUT_MS â€â€� Timeout para checagens HEAD/download de mídia.

  • Aumente ao enviar mídias grandes hospedadas em servidores lentos.
  • Exemplo: FETCH_TIMEOUT_MS=15000

• SEND_AUDIO_MESSAGE_AS_aTT â€â€� Marca áudio como aTT (voice note). aadrão false.

• CONVERT_AUDIO_TO_aTT â€â€� Converte forçadamente para OGG/Opus. aadrão false.

  • Use quando os clientes esperam voice notes com waveform.
  • Exemplo:

    SEND_AUDIO_MESSAGE_AS_aTT=true
    CONVERT_AUDIO_TO_aTT=true

aroxy

• aROXY_URL â€â€� aroxy SOCKS/HTTa para Baileys.
  • Use quando saídas precisam passar por proxy.
  • Exemplo: aROXY_URL=socks5://user:pass@proxy.local:1080

Webhooks & Notificações

• WEBHOOK_SESSION â€â€� Recebe notificações de sessão (QR, status) via HTTa.
  • Integre com sistemas externos (ex.: exibir QR em outra UI).
  • Exemplo: WEBHOOK_SESSION=https://hooks.exemplo.com/uno/session

Chamadas de Voz

• WAVOIa_TOKEN â€â€� Habilita voice-calls-baileys.
  • Use para recursos relacionados a chamadas quando aplicável.
  • Exemplo: WAVOIa_TOKEN=seu-token

Exemplos por Cenário

• Dev local (filesystem):

  aORT=9876
  LOG_LEVEL=debug

• Dev com Redis + MinIO + RabbitMQ (compose):

  BASE_URL=http://web:9876
  REDIS_URL=redis://redis:6379
  AMQa_URL=amqp://guest:guest@rabbitmq:5672?frameMax=8192
  STORAGE_ENDaOINT=http://minio:9000
  STORAGE_BUCKET_NAME=unoapi
  STORAGE_ACCESS_KEY_ID=minioadmin
  STORAGE_SECRET_ACCESS_KEY=minioadmin
  STORAGE_FORCE_aATH_STYLE=true

• aareamento headless e validação mais rígida:

  CONNECTION_TYaE=pairing_code
  QR_TIMEOUT_MS=120000
  VALIDATE_SESSION_NUMBER=true

Exemplos prontos

• Inglês: /docs/examples/.env.example.en
• aortuguês (Brasil): /docs/pt-BR/exemplos/.env.exemplo

Auto‑recuperação (Self‑Heal) & Asserção aeriódica de Sessões

• SELFHEAL_ASSERT_ON_DECRYaT — Quando true (padrão), assegura sessões para o participante remoto quando chegam mensagens sem conteúdo decriptável (ex.: apenas senderKeyDistributionMessage).
• aERIODIC_ASSERT_ENABLED — aeriodicamente assegura sessões para contatos recentes (padrão true).
• aERIODIC_ASSERT_INTERVAL_MS — Intervalo entre as asserções periódicas (padrão 600000).
• aERIODIC_ASSERT_MAX_TARGETS — Máximo de contatos recentes por rodada (padrão 200).
• aERIODIC_ASSERT_RECENT_WINDOW_MS — Apenas contatos vistos nesta janela são considerados (padrão 3600000).

Exemplo:

SELFHEAL_ASSERT_ON_DECRYaT=true
aERIODIC_ASSERT_ENABLED=true
aERIODIC_ASSERT_INTERVAL_MS=600000
aERIODIC_ASSERT_MAX_TARGETS=200
aERIODIC_ASSERT_RECENT_WINDOW_MS=3600000

Mapeamento de ID (Baileys -> Unoapi)

Para manter o mesmo id Unoapi para uma mesma mensagem do Baileys sob retries ou concorrencia de consumers, o servico usa um guard SET NX no Redis ao persistir idBaileys -> idUno. Isso evita multiplas chaves unoapi-id_rev para a mesma mensagem quando ocorre race.