Visão geral
Tickets
Seção intitulada “Tickets”Tickets da empresa da chave. Toda requisição exige o cabeçalho Authorization: Bearer <chave de API>.
Escrita e ações
Criar, alterar e acionar um ticket ficam registrados na linha do tempo dele como feitos pela integração: a origem é API e o autor é o nome da chave usada — nenhuma escrita da API tem usuário do produto por trás. As notificações e as automações disparam exatamente como quando a mesma ação é feita na tela do produto.
Nenhuma operação de escrita aceita parâmetros de consulta: tudo vai no corpo. A única exceção é o DELETE, que não tem corpo e recebe associationStrategy e cancelOpenInvoices na URL. Um parâmetro a mais numa escrita é 400 invalid_query.
Toda escrita e toda ação devolvem o ticket inteiro, lido depois de gravar — o mesmo corpo do GET /v1/tickets/{id}, sem precisar de uma leitura extra. Duas ressalvas sobre esse corpo:
lastActivityAté atualizado fora da transação da escrita e pode voltar com o valor anterior por alguns milissegundos. Quem depende dele relê o ticket em seguida.- Aviso de automação não aparece na resposta. Uma automação de etapa que não pôde rodar (por exemplo, a que atribui o ticket a um agente que não é mais do grupo) não impede a ação: a resposta continua
200e o aviso fica na linha do tempo do ticket, como registro do tipoAUTOMATION. Quem precisa auditar isso lê a linha do tempo.
Corpo inválido em um ticket que está na lixeira: as duas respostas são 422, mas a ordem de verificação muda conforme a ação. start, pause, end-appointment, stage, sla-pause e merge validam o corpo primeiro e respondem validation_failed; workflow verifica a lixeira primeiro e responde ticket_deleted. Campo desconhecido no corpo é recusado antes de tudo, em qualquer ação.