Clint

objetivo o conector clint integra a plataforma fluid aos recursos da api clint, permitindo operações de crm como contatos, organizações, negócios (deals), tags, origens, grupos e usuários é utilizado por clientes , analistas e desenvolvedores para automatizar fluxos comerciais, sincronizar entidades e consultar dados da conta clint doc oficial da api (callout archbee) /callout\[info] para mais informações, acesse o portal de desenvolvedores do clint \ https //clint api readme io/reference/get contacts \ https //ajuda clint digital/pt br/articles/11200658 como funciona a api da clint requisitos (criando conexão) autenticação a api clint utiliza api token enviado via header no conector fluid, a conexão contém apenas um campo obrigatório campo tipo required observações api token string sim campo secreto; não exibido após salvar escopos/permissões o token deve possuir permissão para operar nos recursos usados no fluxo (contatos, deals, etc ) tokens restritos podem gerar http 403 pré requisitos de ambiente a api clint é pública e não exige whitelists de ip webhooks, caso usados, devem ser configurados na própria conta clint observações de segurança não inserir o token diretamente em logs ou mapeamentos regenerar o token em caso de vazamento a fluid armazena o token criptografado 3\ configurando um fluxo o conector organiza recursos sob a propriedade resource , cada um com várias operations , refletindo endpoints da api clint (get/post/delete) parâmetros principais os campos vêm diretamente do schema de configuração exemplos filtros de paginação (\ page, \ per page, \ limit, \ offset) filtros específicos (e mail, telefone, tags, datas, status) corpo da requisição com campos dinâmicos quando post/put dependências e validações operações que exigem \ idmarcam o campo como required no schema campos de corpo, mesmo quando opcionais, devem seguir o tipo definido (string) campos oneofpermitem template ou campos dinâmicos mapeamento fluid ↔ clint o conector expõe diretamente os nomes do clint (ex tag ids, stage id, contact id) o integrador deve mapear seus dados para esses campos no nó do fluxo 4\ recursos e operações a seguir, os recursos detectados no schema, com suas operações e campos contacts operações disponíveis listar contatos get /contacts campos campo tipo required descrição \ page string não número da página \ per page string não registros por página \ email string não filtro por e mail \ phone string não filtro por telefone \ tag ids string não tag ids separados por vírgula \ tag names string não tag names separados por vírgula criar contato post /contacts corpo → template ou campos dinâmicos campo tipo required descrição name string não nome completo email string não e mail phone string não telefone ddi string não ddi username string não username consultar contato por id get /contacts/\ id requires \ id campo tipo required descrição \ id string sim id do contato atualizar contato post /contacts/\ id requires \ id corpo igual ao de criação remover contato delete /contacts/\ id requires \ id adicionar tags post /contacts/\ id/tags remover tags delete /contacts/\ id/tags campos dinâmicos possíveis tag id, tag name organizations operações consultar organização (get /organizations/\ id) atualizar organização (post /organizations/\ id) campos relevantes campo tipo required descrição \ id string sim id da organização name string sim (update) nome da organização deals (negócios) principais operações listar negócios (get /deals) criar negócio (post /deals) consultar negócio (get /deals/\ id) atualizar negócio (post /deals/\ id) remover negócio (delete /deals/\ id) campos da listagem (todos opcionais) incluem filtros como \ page, \ limit, \ offset, \ email, \ phone, \ contact id, \ tag ids, \ stage id, \ status, \ created at start, \ created at end, \ updated stage at start, \ won at start, etc campos para criação campo tipo required descrição origin id string não origem name string não nome do deal phone string não telefone stage id string não fase contact id string sim id do contato email string não email username string não username value string não valor user id string não responsável groups , lost status , origins , tags , users , account todos esses recursos seguem o mesmo padrão listar (get) consultar por id (get) quando aplicável criar/remover (apenas tags suporta create e delete) campos tipicamente opcionais paginação e filtros simples 5\ na prática exemplo de configuração fluxo “listar contatos filtrando por e mail” resource contacts operation lista contatos email "cliente\@exemplo com"page "1"per page "50" boas práticas usar paginação para evitar timeouts validar existência de \ idantes de chamar operações que o exigem preferir templates quando nenhum campo dinâmico é necessário tratar erros http 429 (rate limit), 400 (corpos inválidos), 403 (permissão) 6\ disparando o fluxo manual via botão de execução agendado coleta periódica de contatos/deals evento gatilhos internos da fluid testes devem observar código http corpo retornado headers relevantes, caso disponíveis 7\ observações adicionais a api clint possui paginação em diversos endpoints; respeitar limites do serviço versões da api podem mudar, recomenda se revisar campos periodicamente operações post no clint frequentemente funcionam como "upsert" 8\ conclusão o conector clint provê integração completa com entidades de crm do clint, possibilitando criação, consulta, filtro avançado e sincronização automática de contatos, deals, tags e outros recursos com os schemas fornecidos, o conector está documentado com 100% de cobertura