O sistema utiliza um conjunto padronizado de status para representar o ciclo de vida das mensagens, independentemente do tipo de conexão utilizada.
Embora os status sejam os mesmos para todas as integrações, a forma como cada status é alcançado pode variar de acordo com a existência ou não de um webhook de confirmação de entrega.
Atualmente, existem dois grupos de conexões:
Conexões com webhook de confirmação
Conexões sem webhook de confirmação
Essa diferença é especialmente importante para determinar quando uma mensagem pode ser considerada efetivamente como sent.
Status
Descrição
| Mensagem criada e aguardando o processo de envio. |
| Mensagem considerada enviada com sucesso. |
| Mensagem confirmada como recebida pelo destinatário. |
| Mensagem confirmada como visualizada pelo destinatário. |
| Ocorreu uma falha durante o envio ou processamento da mensagem. |
| Mensagem agendada para ser enviada em uma data/horário futuro. |
São conexões que possuem um webhook responsável por informar o resultado da entrega da mensagem.
Atualmente:
Crazy API
WhatsApp Cloud
Z-API
Nessas conexões, o retorno da requisição inicial de envio não é suficiente para considerar a mensagem como efetivamente entregue.
O status sent é confirmado através do webhook de confirmação.
Fluxo conceitual:
pending
↓
envio da mensagem
↓
confirmação via webhook
↓
sent
↓
received
↓
visualizado
São conexões que não possuem um webhook externo utilizado para confirmar a entrega da mensagem.
Atualmente:
UAZAPI
Evolution API
Conexão Universal
Nessas conexões, o sistema utiliza o retorno HTTP da requisição de envio.
Quando o POST responsável pelo envio retorna HTTP 200, a mensagem é considerada enviada e o status é atualizado diretamente para:
sent
Portanto, não é necessário aguardar uma confirmação externa para essa transição.
sentUma vez que uma mensagem tenha atingido o status:
sent
ela não pode retornar para:
pending
Essa regra é válida para todas as conexões.
pending → sent
É permitido.
sent → pending
Não é permitido.
Essa regra impede que uma mensagem já considerada enviada seja posteriormente tratada como se ainda estivesse aguardando envio.
error é finalO status:
error
representa um estado terminal.
Depois que uma mensagem entra em error, nenhuma outra transição de status deve ocorrer.
sent → error
ou:
scheduled → error
error → pending
error → sent
error → received
error → visualizado
Portanto:
error → [FIM]
errorO status error pode ser atingido em dois cenários.
sentNo fluxo normal, após a mensagem atingir sent, o sistema pode aguardar uma confirmação posterior.
Caso ocorra uma falha nessa etapa, o status será alterado para:
error
A mensagem não continua para received ou visualizado.
Fluxo:
pending
↓
sent
↓
error
A partir de error, o processo é encerrado.
Mensagens com status scheduled possuem uma regra adicional.
Quando chega o horário programado, o sistema tenta realizar o envio.
Existem dois resultados possíveis:
scheduled → pending
A mensagem entra no fluxo normal de envio.
scheduled → error
Nesse caso, a mensagem não passa por pending.
Portanto:
┌──→ pending → sent → received → visualizado
scheduled ────────┤
└──→ error
received e visualizadoOs status received e visualizado representam confirmações posteriores ao envio.
Eles são alcançados através de eventos de confirmação, normalmente provenientes do webhook da integração.
Uma mensagem que já esteja em:
received
ou:
visualizado
não deve ser alterada para error.
Isso ocorre porque esses status representam uma confirmação passiva recebida pelo sistema.
O erro deve ser tratado nas etapas anteriores do processo, e não após uma confirmação de recebimento ou visualização.
sent → received → visualizado
received → error
visualizado → error
Para mensagens que não foram agendadas, o fluxo padrão é:
pending → sent → received → visualizado
Cada etapa representa uma evolução do estado da mensagem.
pending → sent → error
O status error encerra o ciclo.
Mensagens agendadas possuem o status inicial:
scheduled
Quando chega o horário definido para o envio, o sistema tenta iniciar o processo.
scheduled
↓
pending
↓
sent
↓
received
↓
visualizado
scheduled
↓
error
Portanto, existem duas ramificações possíveis a partir de scheduled.
Status Atual
Próximo Status
Condição
|
| Horário agendado atingido e envio iniciado com sucesso |
|
| Falha ao tentar enviar no horário agendado |
|
| Mensagem considerada enviada |
|
| Falha no processo de envio, quando aplicável |
|
| Confirmação de recebimento |
|
| Falha na etapa de confirmação/processamento |
|
| Confirmação de visualização |
|
| Não permitido |
| qualquer outro status | Não permitido |
| qualquer outro status | Não permitido |
Observação: a confirmação de
sentvaria conforme a conexão utilizada.
Integração
Possui webhook de confirmação?
Como sent é confirmado?
Crazy API | Sim | Webhook de confirmação |
WhatsApp Cloud | Sim | Webhook de confirmação |
Z-API | Sim | Webhook de confirmação |
UAZAPI | Não | Retorno HTTP |
Evolution API | Não | Retorno HTTP |
Conexão Universal | Não | Retorno HTTP |
pending
↓
sent
↓
received
↓
visualizado
↓
FIM
pending
↓
sent
↓
error
↓
FIM
scheduled
↓
pending
↓
sent
↓
received
↓
visualizado
↓
FIM
scheduled
↓
error
↓
FIM
De forma simplificada, o ciclo de vida das mensagens pode ser representado da seguinte maneira:
┌───────────────┐
│scheduled/envio│
└───────┬───────┘
│
┌────────────┴────────────┐
│ │
sucesso falha
│ │
▼ ▼
┌─────────┐ ┌─────────┐
│ pending │ │ error │
└────┬────┘ └────┬────┘
│ │
▼ ▼
┌─────────┐ FIM
│ sent │
└────┬────┘
│
┌──────┴──────┐
│ │
sucesso erro
│ │
▼ ▼
┌──────────┐ ┌─────────┐
│ received │ │ error │
└────┬─────┘ └────┬────┘
│ │
▼ ▼
┌────────────┐ FIM
│ visualizado│
└─────┬──────┘
│
▼
FIM
Regra fundamental: os status representam uma evolução do ciclo de vida da mensagem. O sistema não deve permitir regressões ou alterações incompatíveis com as transições definidas nesta documentação.