C C-Connect Documentação

Ler o registo de eventos

Onde procurar quando alguém diz que não recebeu, no painel e pela API.

A pergunta que chega ao suporte é quase sempre a mesma: "o cliente diz que não recebeu". Esta página é como se responde a isso em dois minutos.

No painel

Abre Mensagens e procura pelo endereço. A pesquisa também aceita o assunto e o Message-ID.

A linha traz o estado. Clica nela e abre a gaveta, com a cronologia completa:

  • Injectada, com a hora no fuso da tua conta.
  • MX destino, o servidor que aceitou ou recusou.
  • Saiu por, qual dos relays a levou.
  • Cada evento, com o código SMTP e a resposta do destino, tal como veio.

O Message-ID está lá com um botão de copiar. É o valor que o suporte do destinatário pede quando é preciso procurar do lado deles.

A gaveta de uma mensagem devolvida, com a cronologia completa e o código que o destino respondeu.
A gaveta de uma mensagem devolvida, com a cronologia completa e o código que o destino respondeu.
Encontrar uma devolução e ler o que o destino respondeu.

O que o código SMTP diz

A resposta do destino é a única informação de primeira mão que existe sobre o que aconteceu. Vale a pena lê-la antes de concluir seja o que for.

Resposta O que quer dizer
250 OK Aceite.
550 5.1.1 User unknown O endereço não existe.
550 5.7.1 ... spam Recusada por conteúdo ou por reputação.
452 4.2.2 Mailbox full Caixa cheia; temporário, tentamos outra vez.
421 4.7.0 Too many connections Estamos a enviar depressa de mais para eles; temporário.

Um 5.7.x é o que merece atenção: é o destino a dizer que não gosta da mensagem ou de quem a envia, e repetir não ajuda.

Pela API

Uma mensagem, com tudo o que lhe aconteceu:

curl https://app.c-connect.pt/v1/messages/01JB2XK7Q9R3N8Z6T4V0M5W1YC \
  -H "Authorization: Bearer $CCONNECT_KEY"

O fluxo de eventos, do mais recente para trás:

curl "https://app.c-connect.pt/v1/events?limit=100" \
  -H "Authorization: Bearer $CCONNECT_KEY"

Podes filtrar por message_id e por type.

A paginação é por cursor

A resposta traz um next_cursor, e a página seguinte pede-se com ?cursor=<esse valor>.

Não há page nem offset, e é de propósito. Enquanto percorres as páginas chegam eventos novos, e um offset passa a apontar para outro sítio: ficarias com linhas repetidas e com linhas nunca vistas, sem forma de dar por isso. O cursor anda para trás a partir de um identificador, por isso nada aparece duas vezes.

GET /v1/events?limit=100
  → { "data": [...], "next_cursor": "01JB2X..." }

GET /v1/events?limit=100&cursor=01JB2X...
  → { "data": [...], "next_cursor": null }     ← acabou

Quanto tempo fica

  • Os eventos ficam 30 dias.
  • O conteúdo da mensagem fica o número de dias definido em Definições, e depois é apagado. A linha e a cronologia ficam; o corpo desaparece.
  • A linha da mensagem fica.

O prazo do conteúdo é fixado em cada mensagem quando ela é criada, por isso mudar a definição não apaga nada do que já enviaste, e também não prolonga o que já estava marcado para desaparecer.

Quando a mensagem não está lá

Se procurares e não encontrares nada, a mensagem nunca chegou a entrar. Olha para o teu lado: um 4xx da API que ninguém tratou, uma chave revogada, ou um sistema a apontar ainda para o fornecedor anterior.