Tratamento de erros, novas tentativas e ordenação de chamadas no CRM personalizado (API genérica)

Neste documento, descrevemos o comportamento do recurso de CRM personalizado (API genérica) da plataforma CCAI quando os endpoints de CRM retornam respostas diferentes de HTTP 200 "Success.". Ele serve como uma referência de comportamento para integradores que configuram endpoints de conta e registro de API.

Ordem de execução e relacionamentos de alto nível

Quando uma interação aciona uma integração de CRM personalizada, a plataforma chama seus endpoints nesta ordem:

  1. Operações no nível da conta (conta da API): contato

    Exemplos:

    • Encontrar um contato.

    • Criar um contato.

    • Atualizar um contato.

  2. Operações no nível do registro (registro da API): tíquete ou caso

    Exemplos:

    • Encontre um ingresso.

    • Criar um tíquete.

    • Atualizar um tíquete.

  3. Ações pós-sessão (se configuradas)

    Exemplos:

    • Adicione um comentário ou uma observação.

    • Faça upload de um anexo ou uma transcrição.

    • Aplicar atualizações de finalização.

As etapas anteriores geralmente produzem IDs que as etapas posteriores podem usar. Por exemplo, um contact_id pode ser transmitido para a criação de tíquetes quando incluído no modelo de payload do endpoint, e um ticket_id é necessário para ações pós-sessão em configurações típicas de API genérica. Nem todos os endpoints são configurados para extrair um ID. Consulte Nuance importante: 2xx + ID ausente em endpoints de extração de ID.

Nuance importante: 2xx + ID ausente em endpoints de extração de ID

Nem todos os endpoints de CRM personalizados extraem um ID da resposta que recebem. Esse comportamento se aplica apenas a endpoints configurados com um response_data_location e (para endpoints de criação) um custom_id_location, normalmente endpoints de pesquisa (extraindo o ID de um registro atual) e endpoints de criação (extraindo o ID de um registro recém-criado). Endpoints como comentários, anexos e atualizações não extraem IDs das respostas.

Impacto da falta de ID em endpoints de extração de ID

  • Para endpoints de pesquisa: uma resposta 200 OK sem registro correspondente (e, portanto, sem ID extraível) é um comportamento normal de "não encontrado". Se a instância tiver skip_account_creation ou skip_record_creation ativado, a plataforma vai prosseguir intencionalmente com um contact_id ou ticket_id nulo em vez de tentar a criação. Esse é o comportamento esperado nessas configurações e não é uma configuração incorreta.

  • Para endpoints de criação: uma resposta 200 OK que não inclui o ID recém-criado no local configurado é um problema de configuração ou de contrato de resposta. A solicitação HTTP foi bem-sucedida, então as novas tentativas não serão acionadas, mas as etapas downstream podem continuar com dados ausentes.

  • Em ambos os casos, a falha (quando é uma falha) aparece como dados ausentes, em vez de um erro de endpoint, o que pode ser confuso durante a depuração.

Orientações para integradores

  • Para operações de criação, faça com que o retorno do ID esperado no local configurado faça parte do contrato de sucesso, não apenas o retorno de 2xx. Trate um ID ausente como um problema de configuração ou de contrato de resposta que vale a pena investigar.

  • Para operações de pesquisa, é aceitável retornar 200 OK sem correspondência. Se sua instância depende intencionalmente de padrões de "pesquisa sem criação" (por exemplo, skip_account_creation = true), documente essa decisão para que os endpoints downstream saibam como lidar com IDs ausentes de maneira adequada.

  • No teste, verifique se:

    • Para endpoints de criação, o ID está presente de forma confiável na resposta e no local exato configurado no CRM personalizado.

    • Para endpoints de pesquisa, o comportamento downstream da plataforma corresponde à configuração da flag de pulo da instância.

Tratamento de erros: visão geral

Quando um endpoint retorna uma resposta de falha (não 2xx) ou não responde:

  • A plataforma pode tentar fazer a solicitação novamente:

    • Uma vez imediatamente para alguns status.

    • Por um período mais longo para falhas que podem ser repetidas.

  • As etapas downstream podem ser atrasadas enquanto a plataforma continua tentando uma etapa upstream.

  • Algumas falhas são tratadas como não repetíveis (por exemplo, falhas de configuração ou validação).

As regras detalhadas de repetição estão descritas em Comportamento de repetição e espera. A relação entre falhas e chamadas downstream é descrita em Regras de encadeamento e dependência.

Regras de encadeamento e dependência

O comportamento personalizado do CRM é regido pela configuração do CRM da sua instância, especificamente as configurações documentadas em Ignorar a criação de conta e registro do CRM. Este documento se refere a essas configurações pelos nomes de configuração de back-end (skip_account_creation, skip_account_lookup, skip_record_creation), já que elas aparecem dessa forma nos exemplos de configuração JSON a seguir.

Nessas configurações, a plataforma tende a continuar a cadeia quando possível, por exemplo, criando um contato anônimo quando a pesquisa falha e a criação de conta está ativada, em vez de sempre "interromper".

Impacto de falhas na conta em operações de registro

A etapa de registro (tíquete/caso) pode ser executada mesmo quando a etapa de conta não produz um contato, mas o comportamento exato depende da configuração da instância.

Dependendo da configuração, a plataforma pode:

  • Criar um contato anônimo como substituto e continuar com a criação do tíquete.

  • Prossiga para as etapas de gravação sem um contact_id quando a pesquisa ou a criação de conta estiver configurada para ser ignorada.

O que isso significa para seus endpoints

  • A ausência de contact_id na criação do tíquete geralmente indica uma configuração de instância em que a pesquisa ou a criação de conta está desativada.

  • Se a instância exigir contas, trate a ausência de contact_id como um sinal que vale a pena investigar, em vez de inserir tíquetes silenciosamente sem um contato.

  • Se a configuração permitir intencionalmente a criação de tíquetes sem um contato, verifique se o endpoint do tíquete lida com esse caso de maneira explícita e previsível.

Impacto de falhas de gravação em ações pós-sessão

Para configurações de API genéricas em que a pesquisa de tíquetes está configurada, a plataforma não envia chamadas pós-sessão, como call_finished, chat_finished, email_finished, save_call_recording, save_chat_history, update_ticket e done_ticket, até que exista um ticket_id.

Se um endpoint pós-sessão for invocado sem um ticket_id, isso geralmente indica uma das seguintes condições:

  • A pesquisa de tíquetes está desativada para a configuração da instância, o que é incomum para uma configuração de API genérica típica.

  • O modelo de payload omitiu a variável ticket_id, que é um problema de configuração que vale a pena investigar.

O que isso significa para seus endpoints

  • Trate a ausência de ticket_id em chamadas pós-sessão como um sinal de configuração que vale a pena investigar, não como um comportamento esperado a ser absorvido silenciosamente.

  • Se a configuração intencionalmente não exigir a pesquisa de tíquetes, configure os endpoints pós-sessão para lidar com um ticket_id ausente de maneira adequada. Por exemplo, registre o problema e a operação nula ou retorne uma mensagem de erro clara e bem estruturada em vez de falhar.

Comportamento de nova tentativa e espera

As novas tentativas acontecem em três camadas:

  1. Nova tentativa imediata no nível HTTP (uma segunda tentativa rápida).

  2. Nova tentativa no nível do adaptador (recuperação rápida para falhas de rede e respostas temporárias específicas).

  3. Novas tentativas no nível do comando (novas tentativas de cauda longa ao longo de dias).

Nova tentativa imediata no nível HTTP (nova tentativa rápida)

Para determinados status temporários, a plataforma faz até duas tentativas no total (uma tentativa inicial + uma nova tentativa imediata). Isso geralmente se aplica aos seguintes status de erro:

  • 408, 413, 429, 500, 502, 503, 504, 521, 522 e 524.

Nova tentativa no nível do adaptador (recuperação rápida de rede)

Entre a chamada HTTP e a programação no nível do comando, uma camada de nova tentativa intermediária no adaptador do CRM (command_runner.js) processa falhas que não produzem uma resposta HTTP ou que correspondem a mensagens temporárias específicas:

  • Nova fila imediata: acionada por erros no nível de TCP/soquete: ECONNRESET, ENOTFOUND, ESOCKETTIMEDOUT, ETIMEDOUT, ECONNREFUSED, EHOSTUNREACH, EPIPE, EAI_AGAIN. São falhas de rede que ocorrem antes do recebimento de uma resposta HTTP.

  • Nova tentativa com atraso de 30 segundos: acionada quando a mensagem de erro é "Too Early" (HTTP 425), "Service Unavailable" ou "Unordered Collection".

  • Não repetível nesta camada: todo o restante é transferido para a programação de repetição no nível do comando (camada 3).

Por que isso é importante para integradores

Esses erros ocorrem quando a plataforma não consegue estabelecer ou manter uma conexão TCP com o endpoint, o que geralmente indica um problema no servidor (servidor inativo, recusando conexões ou interrompendo a conexão no meio da solicitação), não apenas na infraestrutura interna. O efeito prático é que algumas falhas de rede se recuperam muito mais rápido do que a programação de sete dias no nível do comando, geralmente em segundos.

Novas tentativas no nível do comando (~7 dias, 14 tentativas)

Se uma operação falhar e puder ser repetida, a plataforma poderá tentar novamente até 14 vezes em aproximadamente 7 dias, usando esta programação:

  10s → 1m → 5m → 30m → 1h → 6h → 6h → 12h → 1d → 1d → 1d → 1d → 1d → 1d

Esse comportamento de repetição de cauda longa pode ser aplicado a:

  • Operações de contas.

  • Operações de registro.

  • Operações pós-sessão.

Falhas que não podem ser repetidas

Algumas falhas são tratadas como não repetíveis, por exemplo:

  • Falhas de configuração ou validação (por exemplo, endpoints obrigatórios não estão configurados ou estão configurados incorretamente).

  • Determinadas categorias de erro interno detectadas pela plataforma.

Se você precisar garantir que uma falha seja tratada como permanente (sem novas tentativas), entre em contato com o suporte ou com a equipe de implementação para confirmar a maneira correta de indicar uma falha não repetível na sua configuração específica.

Tempos limite e falhas de rede

A plataforma lida com dois caminhos distintos:

  1. Tempos limite no nível do aplicativo: quando o tempo limite HTTP configurado é excedido (a solicitação foi enviada, mas nenhuma resposta foi recebida), a plataforma gera um erro interno que pode ser repetido no nível do comando (camada 3). Isso significa que a solicitação segue a programação de espera padrão (até 14 novas tentativas em cerca de 7 dias).

  2. Erros no nível de TCP/soquete: quando a conexão falha no nível da rede antes que uma resposta HTTP seja recebida (por exemplo, ETIMEDOUT, ESOCKETTIMEDOUT e ECONNREFUSED), a camada do adaptador (camada 2) captura esses erros e coloca o comando na fila novamente. A recuperação dessas falhas costuma ser muito mais rápida, geralmente em segundos, em vez de seguir o cronograma de sete dias.

Por que a distinção é importante

  • Um tempo limite do aplicativo (o servidor aceitou a conexão, mas não respondeu a tempo) tenta novamente mais devagar.

  • Uma falha no nível da rede (não foi possível acessar o servidor) tenta novamente com muito mais rapidez.

  • Em ambos os casos, a solicitação pode ter sido parcialmente processada. Portanto, os endpoints precisam ser idempotentes. Consulte Como criar endpoints resilientes (idempotência e dicas de design).

Código de status e matriz de comportamento de tempo limite (com exemplos)

As tabelas e os exemplos a seguir descrevem como a plataforma da CCAI lida com diferentes códigos de status HTTP, tempos limite e falhas de rede.

Tabela de resumo de resultados

As linhas relacionadas ao ID na tabela a seguir se aplicam apenas a endpoints configurados para extrair um ID da resposta, como endpoints de pesquisa ou criação. A maioria dos outros endpoints não realiza a extração de ID de resposta.

Resultado Exemplos Nova tentativa imediata de HTTP? Novas tentativas de cauda longa (~7 dias)? Impacto downstream
Sucesso para um endpoint de extração de ID 2xx + ID esperado presente no local de resposta configurado. Não Não O downstream continua com o ID extraído.
Pesquisa sem correspondência 2xx, mas nenhum registro foi encontrado no local configurado. Não Não Comportamento normal de "não encontrado". Com skip_account_creation ou skip_record_creation ativados, o downstream prossegue intencionalmente com IDs nulos.
Criar 2xx de retorno sem um ID 2xx de um endpoint de criação, mas o ID do novo registro está ausente no local configurado. Não Não O downstream pode continuar com dados ausentes. Trate como um problema de configuração ou de contrato de resposta.
Sucesso de um ID que não extrai IDs 2xx de endpoints, como ações de observação, atualização ou anexo que não extraem IDs. Não Não O downstream prossegue de acordo com a cadeia de comandos e a configuração da instância.
Erro temporário 408, 413, 429, 500, 502, 503, 504, 521, 522 e 524. Sim (duas tentativas no total) Muitas vezes sim As etapas downstream podem ser atrasadas enquanto as novas tentativas ocorrem.
Outros erros 400, 401, 403, 404 e outro 4xx/5xx. Não Muitas vezes sim As etapas downstream podem ser atrasadas enquanto as novas tentativas ocorrem.
Falha de configuração/validação configuração incorreta, endpoints ausentes. N/A Não A cadeia pode ser interrompida ou concluída parcialmente, dependendo da configuração.
Falha no nível da rede (TCP/soquete) ECONNRESET, ENOTFOUND, ESOCKETTIMEDOUT, ETIMEDOUT, ECONNREFUSED, EHOSTUNREACH, EPIPE e EAI_AGAIN. N/A Não (processado pelo adaptador da camada 2) O adaptador é colocado de volta na fila imediatamente. A recuperação costuma ser rápida (segundos). As etapas downstream podem ser atrasadas brevemente.
Tempo limite no nível do aplicativo HTTP timeout exceeded (nenhuma resposta recebida). N/A Muitas vezes sim (camada 3) As etapas downstream podem ser atrasadas enquanto as novas tentativas no nível do comando ocorrem.

Exemplo prático com configuração mínima de API genérica

Uma configuração de API genérica de CRM personalizada de referência com os três endpoints usados pela cadeia: encontrar ou criar contato, encontrar ou criar tíquete e um comentário pós-sessão. Use isso como ponto de partida e adapte às especificidades do seu CRM.

Configurações no nível da instância

{
  "lookup_method": "genericApi",
  "auth_method": "basic",
  "basic_auth_username": "ccai-integration",
  "basic_auth_password": "<secret>",
  "api_request_timeout": 10,
  "case_lookup_url": "https://crm.example.com/api/cases/{RECORD_ID}",
  "contact_lookup_url": "https://crm.example.com/api/contacts/{ACCOUNT_ID}",
  "skip_account_lookup": false,
  "skip_account_creation": false,
  "skip_record_creation": false
}

Formatos de resposta

O formato de resposta do CRM é específico do cliente. response_data_location é um caminho no estilo lodash que chega ao objeto relevante dentro do corpo da resposta analisado. Não é necessário unir as respostas em um campo data de nível superior. Os exemplos a seguir mostram formas planas realistas por padrão.

Por exemplo, um CRM que aninha recursos em data.contact definiria response_data_location: "data.contact" e um corpo de resposta de { "contact": { "id": "c_99812" } }. O restante da configuração não é alterado.

Endpoint 1: contact_find_endpoint

Pesquisa um contato por número de telefone ou e-mail.

{
  "request_url": "https://crm.example.com/api/contacts/search?phone={PHONE_NUMBER}&email={EMAIL}",
  "request_method": "GET",
  "request_parameters": {},
  "response_data_location": "data"
}

Sucesso: contato encontrado

200 OK
Content-Type: application/json
{ "id": "c_42018", "first_name": "Jane", "last_name": "Doe" }

Contato não encontrado

404 Not Found

A plataforma trata 404 como "não encontrado" (não é um erro). Se skip_account_creation for falso, o fluxo vai para contact_create_endpoint.

Padrão alternativo de "não encontrado": também válido

200 OK
{}

Alguns CRMs retornam 200 OK com dados vazios em vez de 404 quando nenhum registro corresponde. A plataforma lida com ambos de forma equivalente: ambos acionam a próxima etapa (criação, se ativada).

Falha temporária

503 Service Unavailable
}

Aciona a nova tentativa HTTP imediata da camada 1 (duas tentativas no total). Se ainda houver falha, recorra às novas tentativas no nível do comando da Camada 3.

Endpoint 2: contact_create_endpoint

Cria um contato. O campo custom_id_location informa à plataforma onde encontrar o ID do novo contato na resposta.

{
  "request_url": "https://crm.example.com/api/contacts",
  "request_method": "POST",
  "request_parameters": {
    "first_name": "{FIRST_NAME}",
    "last_name": "{LAST_NAME}",
    "email": "{EMAIL}",
    "phone": "{PHONE_NUMBER}",
    "external_session_id": "{SESSION_TYPE}-{SESSION_ID}"
  },
  "response_data_location": "data",
  "custom_id_location": "id"
}

Criação bem-sucedida

201 Created
{ "id": "c_99812", "first_name": "John", "last_name": "Doe" }

2xx, mas sem ID no local configurado

200 OK
{}

O endpoint retornou 200 OK sem id no local configurado. A plataforma registra um aviso e encaminha um contact_id nulo para downstream (nenhuma exceção é gerada, nenhuma nova tentativa é feita). Trate isso como um problema de configuração: response_data_location e custom_id_location precisam gerar um ID de forma confiável para qualquer 2xx que o endpoint retornar desse caminho.

Endpoint 3: case_create_endpoint

Cria um tíquete. O contact_id da etapa anterior está disponível como {ACCOUNT_ID}.

{
  "request_url": "https://crm.example.com/api/cases",
  "request_method": "POST",
  "request_parameters": {
    "subject": "{TICKET_SUBJECT}",
    "description": "{TICKET_DESCRIPTION}",
    "contact_id": "{ACCOUNT_ID}",
    "channel": "{CHANNEL}",
    "external_session_id": "{SESSION_TYPE}-{SESSION_ID}"
  },
  "response_data_location": "data",
  "custom_id_location": "id"
}

Criação bem-sucedida

201 Created
{ "id": "case_77103", "status": "new" }

Com response_data_location: "data", a plataforma resolve o caminho para o corpo da resposta analisado. Em seguida, ele lê o campo em custom_id_location: "id" → ticket_id = "case_77103", que flui para a pós-sessão.

Endpoint 4: case_comment_endpoint

Esse endpoint adiciona um comentário de resumo da sessão ao tíquete após o término da chamada ou do chat. A variável RECORD_ID carrega o ticket_id produzido pela etapa 3.

{
  "request_url": "https://crm.example.com/api/cases/{RECORD_ID}/comments",
  "request_method": "POST",
  "request_parameters": {
    "body": "{COMMENT_BODY}",
    "agent_email": "{AGENT_EMAIL}",
    "channel": "{CHANNEL}",
    "duration": "{CALL_DURATION}",
    "external_session_id": "{SESSION_TYPE}-{SESSION_ID}"
  }
}

Para instâncias de API genéricas com case_lookup_url configurado, a plataforma não vai enviar esse endpoint até que a etapa de criação do tíquete seja concluída. Portanto, a ausência de RECORD_ID aqui significa um problema de configuração, não um estado temporário.

Variação: criação de conta desativada

Este exemplo é muito semelhante ao anterior, que mostra uma configuração mínima de API genérica, exceto que aqui sua instância não permite criar contatos no CRM. Enquanto a pesquisa de contas é executada, a criação não é.

Alteração nas configurações da instância

{
  "skip_account_creation": true,
  "skip_account_lookup": false
}

As mudanças nas configurações da instância incluem estes comportamentos:

  • A etapa da conta chama apenas contact_find_endpoint. Se nenhum contato for encontrado, ele não chamará contact_create_endpoint.

  • A etapa de gravação recebe um contact_id nulo. A plataforma prossegue para a criação de tíquetes sem um contact_id: {ACCOUNT_ID} é resolvido como vazio, e o campo contact_id é totalmente removido do payload case_create_endpoint.

  • Isso significa que o endpoint de criação de tíquetes precisa ser capaz de criar tíquetes sem um contact_id nessa configuração. Se o CRM exigir um contato associado para cada tíquete, essa configuração será incompatível.

Padrão defensivo em case_create_endpoint

Sem um contact_id, seu CRM tem menos contexto sobre o autor da chamada do que teria normalmente. Use o auxiliar =DEFAULT_VALUE para capturar as informações de identificação pessoal disponíveis na solicitação e transmiti-las como um indicador substituto:

"request_parameters": {
  "subject": "{TICKET_SUBJECT}",
  "contact_id": "{ACCOUNT_ID}",
  "contact_origin": "=DEFAULT_VALUE(\"{EMAIL}\", \"{PHONE_NUMBER}\", \"anonymous\")"
}

O auxiliar =DEFAULT_VALUE escolhe o primeiro valor não vazio, para que seu CRM receba um e-mail ou número de telefone quando um estiver disponível, e a string literal "anonymous" somente quando nenhum estiver disponível, o que é útil para sinalizar tíquetes que não têm dados de contato de identificação anexados.

Variação: fluxo de tíquetes somente de pesquisa (sem criação de registro)

As operações da conta são executadas normalmente, mas a criação de tíquetes é desativada. A integração só anexa comentários a tíquetes existentes que aparecem na pesquisa.

Alteração nas configurações da instância

{
  "skip_record_creation": true,
  "case_lookup_url": "https://crm.example.com/api/cases/{RECORD_ID}"
}

As mudanças abrangem estes comportamentos:

  • A etapa de registro chama case_find_endpoint e usa o ticket retornado. Se nenhum tíquete for encontrado, a cadeia será interrompida na etapa de registro, e case_create_endpoint não será invocado.

  • Os endpoints pós-sessão (case_comment_endpoint, case_update_endpoint e semelhantes) só são enviados quando um tíquete é encontrado. A proteção ready? do lado do Rails garante que esses comandos permaneçam na fila (e, por fim, expirem) se nenhum ticket_id for materializado.

  • Implicação prática: nessa configuração, os endpoints pós-sessão vão receber apenas sessões vinculadas a um tíquete conhecido. Não é necessário processar a ramificação "missing ticket_id".

A plataforma expõe SESSION_TYPE e SESSION_ID como variáveis de modelo. A maneira mais limpa de aplicar o padrão de chave composta é incorporá-lo diretamente em cada corpo de solicitação relevante. Assim, seus endpoints têm a chave canônica para trabalhar, sem lógica adicional do seu lado:

"request_parameters": {
  "...your fields...": "...",
  "ccai_session_key": "{SESSION_TYPE}-{SESSION_ID}"
}

Para a mesma chamada, cada nova tentativa de cada endpoint na cadeia (conta > registro > pós-sessão) vai produzir o mesmo ccai_session_key. Use-o como âncora de eliminação de duplicação na lógica de criação ou upsert do CRM. Por exemplo, um upsert em (ccai_session_key, endpoint_kind) vai absorver as novas tentativas com segurança sem produzir registros duplicados.

Como criar endpoints resilientes (idempotência e dicas de design)

Como as solicitações podem ser repetidas (tentativa imediata + tentativas ao longo de dias), seus endpoints precisam ser idempotentes:

  • Use um identificador de interação composto estável como sua chave de idempotência:

    • Combine o tipo de sessão com o ID da sessão, por exemplo, call-12345 ou chat-12345.

    • Não confie apenas em call_id ou chat_id. Os IDs de voz e chat podem se sobrepor porque cada sequência pode começar em 1.

  • Se você receber o que parece ser uma solicitação duplicada:

    • Analise o payload para determinar se ele é realmente uma cópia. Alguns endpoints compartilhados, como os de comentários ou notas, podem ser usados por vários tipos de comando.

    • Para operações de criação, solicitações duplicadas não devem ocorrer em condições normais de sucesso, mas podem ocorrer se o CRM processou a solicitação e retornou um erro ou atingiu o tempo limite antes que a plataforma recebesse uma resposta de sucesso.

    • Quando uma solicitação de criação duplicada for confirmada, retorne o ID do registro criado anteriormente em vez de outro registro.

  • Trate os IDs ausentes explicitamente:

    • A ausência de contact_id na criação do tíquete geralmente indica uma configuração em que a pesquisa ou a criação de contas está desativada. Se sua instância exigir contas, investigue-a em vez de criar tíquetes silenciosamente sem contatos.

    • A ausência de ticket_id em chamadas pós-sessão não é esperada em configurações de API genéricas típicas em que a pesquisa de tíquetes está configurada. Verifique a configuração de pesquisa de tíquetes e os modelos de payload antes de tratar a solicitação como uma operação normal sem efeito.

  • Para atualizações, defina os campos com valores específicos em vez de incrementar contadores, para que as chamadas repetidas sejam seguras.

Solução de problemas e observabilidade

Ao depurar uma integração de CRM personalizada, lembre-se destes padrões:

  • Chamadas repetidas para o mesmo endpoint:

    • Compare os carimbos de data/hora com a programação de novas tentativas em Novas tentativas no nível do comando (~7 dias, 14 tentativas).

    • Correlacione eventos usando o identificador de sessão composto, como tipo de sessão + ID da sessão de chamada ou chat.

    • Os registros exportados da CCAI Platform podem ajudar a mostrar o ID da sessão de chamada ou chat com os eventos da API para rastreabilidade.

    • Verifique se o endpoint está retornando de forma consistente um erro que pode ser repetido (por exemplo, 500) em vez de uma falha de configuração que não pode ser repetida.

  • Novas tentativas que "não vão parar":

    • Inspecione as respostas de erro que o endpoint está retornando.

    • Se você pretendia uma falha permanente, entre em contato com o suporte para receber orientações sobre como indicar um erro não repetível para sua configuração.

  • O endpoint nunca foi chamado:

    • Verifique se o seguinte foi realizado:

      • As etapas upstream (conta/registro) foram concluídas com sucesso e produziram os IDs necessários.

      • O endpoint está configurado e ativado corretamente nas configurações personalizadas de CRM.

    • Um endpoint configurado incorretamente ou desativado, ou uma falha anterior na cadeia, pode impedir a execução de determinadas etapas.

  • Como correlacionar registros:

    • Registre a solicitação e a resposta completas, incluindo o ID de interação (call_id / chat_id).

    • Use esse ID para correlacionar os registros do CRM com o comportamento da plataforma ao longo do tempo (especialmente durante as novas tentativas).