Consultar e manter usuários

  • GET /v2/api/external/{ApiID}/listUsers aceita pageNumber como inteiro e searchParam como string.
  • GET .../getUserStatus recebe userId como inteiro.
  • POST .../createUser publica email, password, name e profile como strings.
  • POST .../updateUser publica userId como número e name e email como strings.
Formulário de criação de usuário com campos de identificação e perfil
A interface possui opções adicionais. Pela API, envie somente os campos publicados na rota escolhida.
  1. 1

    Consulte com searchParam e compare nome e e-mail no retorno antes de criar para evitar duplicidade.

  2. 2

    Valide profile e a política de senha no ambiente de homologação.

  3. 3

    Nunca registre password, token ou uma resposta completa de usuários.

  4. 4

    Depois da criação, confirme o usuário e configure permissões e vínculos pela interface quando necessário.

Criar e manter filas

  • POST .../createQueueData apresenta no exemplo atual os campos name, color, greetingMessage e userId.
  • GET .../listQueues consulta as filas.
  • POST .../updateQueueData/{id} apresenta no exemplo atual name, color, greetingMessage e userId; use o ID obtido ou confirmado no mesmo ambiente.
  • POST .../deleteQueueData/{id} remove a fila e apresenta um objeto JSON vazio no exemplo de corpo.
Formulário de nova fila de atendimento
Nome e cor aparecem na tela e nos exemplos atuais da API; horário e demais controles visuais não integram esse corpo publicado.

Manter etiquetas e motivos

  • Etiquetas: os exemplos atuais de createTag e updateTagData/{id} usam name, color e isActive; deleteTag/{id} apresenta corpo vazio. GET .../listTags permanece a consulta de referência.
  • Motivos: GET .../listReasons consulta; os exemplos atuais de createReason e updateReason/{id} usam name e color; deleteReason/{id} apresenta corpo vazio.
  • Use exatamente o ID obtido ou confirmado na mesma instância e confira os nomes de campo na documentação interativa antes de executar a escrita.
Formulário de criação de etiqueta com nome e cor
Palavra-chave gatilho e outras opções visuais não integram o contrato publicado de createTag.
Tela de configuração dos motivos de fechamento
A interface mostra motivos de fechamento; confirme no ambiente qual cadastro a versão associa às rotas genéricas de Reason antes de alterar.

Manter lanes do Kanban

  • POST .../createKanban recebe name como string.
  • GET .../listKanban consulta as lanes.
  • POST .../updateKanban/{id} recebe name como string; id é publicado como string.
  • POST .../deleteKanban/{id} remove a lane, usa id como string e não publica campos no corpo.
Configuração visual de lanes do Kanban
A cor mostrada na interface não faz parte do corpo publicado das rotas de Kanban.

Usar listagens e paginação corretamente

  • listContacts usa pageNumber; listTickets também usa pageNumber; listOpportunities usa page e limit.
  • Somente listTickets documenta os estados open, pending e closed nesse conjunto.
  • listAutoReplies, listChatFlows e listFastReplies não publicam parâmetros adicionais nem schema de resposta.
  • queuesIds e whatsappIds existem em listTickets, mas o formato de separação não está explicado no contrato público.
  1. 1

    Consulte e pesquise antes de criar qualquer cadastro.

  2. 2

    Use IDs apenas no mesmo ambiente que os retornou.

  3. 3

    Altere um registro de teste por vez e reliste depois do POST.

  4. 4

    Após timeout, pesquise novamente antes de repetir.

  5. 5

    Exclua somente depois de remover dependências e obter aprovação.