Pular para o conteúdo principal

Visão geral

Mudanças que afetam as chamadas que você já faz, das mais recentes para as mais antigas. Alterações aditivas, como um novo endpoint ou campo opcional, não são listadas aqui, exceto quando substituem algo que será removido; elas aparecem na referência da API REST quando são disponibilizadas.
As entradas antigas abaixo não registraram datas de vigência. As datas de implantação não foram verificadas, e a ordem das entradas não define uma data de lançamento. A data de remoção dos filtros de lista obsoletos ainda não foi anunciada. Continue usando o contrato atual documentado até a publicação de uma mudança efetiva e use os endpoints de consulta disponíveis em novas integrações.

Melhorias na documentação

Esta revisão esclarece o contrato existente da API e apresenta guias de integração por tarefa. Ela renomeia o recurso de landing pages para Custom Connections, explica a reutilização e a recuperação de conversas outbound e melhora as orientações de erros e webhooks. As assinaturas existentes da API e as URLs de documentação /lead-capture são preservadas. A data de revisão da documentação não é uma data de implantação ou descontinuação da API.

A criação de uma conversa pode recuperar uma conversa liberada

POST /conversations costumava retornar 409 BRIDGE_PROVIDER_CHANNEL_0001 quando nenhuma linha estava livre. Agora, se os Contatos solicitados tiverem uma conversa liberada com recuperação, ela é recuperada e retornada com 201 e seu id existente. Portanto, você pode receber um id que já armazenou. Se essa conversa tiver outros Contatos ou linhas, a requisição retorna 409 BRIDGE_CONVERSATION_0105. Veja os detalhes na referência da API REST.

Encontre um contato ou usuário por um identificador

Essa mudança removerá parâmetros de query que existem hoje. Eles ainda funcionam e estão marcados como obsoletos na referência da API REST. A data em que deixarão de ser aceitos será publicada aqui antes da mudança; os endpoints de consulta que os substituem já estão disponíveis.

O que muda

Disponível agora: GET /contacts/lookup e GET /users/lookup retornam um contato ou usuário do Bridge — chamado de usuário interno na referência da API — por um identificador. Obsoleto, com remoção prevista: os endpoints de listagem deixarão de filtrar. GET /contacts e GET /users manterão apenas limit e cursor. Depois da remoção, o parâmetro será rejeitado, não ignorado. Enviá-lo retornará 400 com BRIDGE_CORE_0103, e a resposta identificará o parâmetro. Essa decisão é intencional: uma chamada que ignorasse silenciosamente o filtro retornaria a primeira página de todo o workspace, permitindo que você a interpretasse como um resultado correspondente à busca.

O que fazer

Se você pesquisa por celular ou e-mail, migre para o endpoint de consulta correspondente. Ele retorna o mesmo objeto que a lista fornece em cada linha e retorna 404 quando não há correspondência. type aceita os tipos de identificador já usados pela API em outros contextos: os mesmos valores de identifierType de um participante de conversa. Contatos aceitam ID, EMAIL e PHONE; usuários do Bridge aceitam ID e EMAIL, pois o celular de um usuário interno não é um identificador consultável no Bridge. ID é aceito pelo mesmo motivo: um código que já trabalha com o par {identifierType, identifier} não deve precisar tratar um dos valores de forma diferente para montar outra URL. Ele retorna exatamente o mesmo resultado de GET /contacts/{contactId}, que continua sendo a URL canônica de um contato. Prefira essa URL quando já tiver o ID.
Um PHONE é interpretado da mesma forma que o celular enviado na criação de um contato: números sem código de país usam o país padrão do workspace, e espaços e separadores são ignorados. Em um EMAIL, o domínio é convertido para minúsculas, mas a parte local é comparada exatamente como foi enviada.
Um celular em formato internacional começa com +, que precisa ser codificado como %2B na query string. A maioria dos clientes HTTP faz isso quando você fornece os parâmetros em um mapa, em vez de montar a URL manualmente.
Um value incompatível com seu type, como e-mail, celular ou UUID malformado, é rejeitado com 422 e BRIDGE_CORE_0101 antes de qualquer consulta. Trate esse caso separadamente de 404 se repassar diretamente dados informados por usuários: um significa você enviou algo que não é um identificador; o outro, ninguém neste workspace tem esse identificador. Se você filtra usuários do Bridge por status, leia status em cada linha. Ele é calculado, não armazenado, e já aparece em todas as respostas. Hoje, a lista retorna apenas usuários ativos, a menos que você envie status; após a remoção do parâmetro, ela retornará usuários ativos e desabilitados. O mesmo vale para GET /users/lookup: ele retorna o usuário do Bridge ativo ou desabilitado, priorizando o ativo quando um e-mail corresponde aos dois. Hoje, GET /users?email= não retorna um usuário desabilitado. Portanto, confira status na resposta se sua aplicação deve agir apenas sobre usuários ativos. Se você pesquisa contatos por nome, não haverá substituição; entenda o que deixará de estar disponível. O parâmetro encontra apenas o nome completo exato: primeiro nome, um espaço e sobrenome. Ele nunca encontra prefixos, trechos do nome ou apenas o sobrenome. Se funciona no seu caso, você já está fornecendo o nome completo. Se você filtra contatos por responsável, não haverá substituição. Liste a página e filtre por ownerId no seu próprio código. ownerId é o ID do usuário do Bridge responsável pelo contato, não um e-mail. Obtenha-o uma vez com GET /users/lookup?type=EMAIL&value=… e compare com seu id.

Por quê

Filtrar por esses parâmetros faz o custo da chamada depender do tamanho do workspace, não do tamanho da resposta. Buscar um contato por telefone em um workspace grande exige ler dezenas de milhares de registros para retornar um único resultado. Pedir uma página maior torna a operação mais lenta, não mais rápida. Os endpoints de consulta leem apenas os registros que contêm o identificador. Por isso, os filtros estão sendo removidos, em vez de corrigidos: quando existe uma substituição, ela é estritamente melhor. A pesquisa por nome, que não tem substituição, nunca encontrou nada além do nome completo exato.

Tópicos relacionados