Webhooks Clinicarx (1.1.9)

Este gatilho new-appointment é responsável por notificar novos agendamentos, o cliente deve indicar a url que deverá ser acionada por esse gatilho, se preferir para distinguir o gatilho dos demais o mesmo poderá receber ao final da url a path /appointment/new. Ex: https://www.SeuEndpoint.com/appointment/new

No disparo deste webhook, os seguintes campos serão sempre enviados com valor null:

• scheduled_duration
• performed_start_at
• performed_end_at
• performed_duration

Isso ocorre porque, neste momento, o agendamento ainda não foi realizado. Esses campos representam informações que só estarão disponíveis após o agendamento e/ou execução da atividade. O que os desenvolvedores devem considerar:

• Não trate esses campos como ausentes: eles estarão presentes no payload, porém com valor null.
• Não utilize valores padrão (como 0 ou datas fictícias) para substituir null.
• Planeje sua integração assumindo que esses campos serão nulos até que o processo de agendamento seja concluído.

ℹ️ Em resumo: sempre espere esses campos com valor null no disparo inicial do webhook.

---

O campo title será enviado como null somente para agendamentos criados diretamente na plataforma Clinicarx. Agendamentos criados via API comercial podem trazer esse campo preenchido.

Exemplo com campo preenchido:

  {
    "title": "Consulta de acompanhamento"
  }

ℹ️ Planeje sua integração considerando que o campo estará presente, mas pode ser nulo dependendo da origem do agendamento.

---

O campo annotations será enviado como null quando o usuário não preencher o campo de observações na plataforma ou quando o agendamento for criado via API comercial sem esse valor, já que o preenchimento não é obrigatório.

Exemplo com campo preenchido:

{
  "annotations": "Próxima dose"
}

ℹ️ Planeje sua integração considerando que o campo estará presente, mas pode ser nulo ou vazio dependendo do comportamento do usuário ou da origem do agendamento.

Este gatilho edit-appointment é responsável por notificar quando um agendamento é alterado/editado, o cliente deve indicar a url que deverá ser acionada por esse gatilho, se preferir para distinguir o gatilho dos demais o mesmo poderá receber ao final da url a path /appointment/edit. Ex: https://www.SeuEndpoint.com/appointment/edit

No disparo deste webhook, os seguintes campos serão sempre enviados com valor null:

• scheduled_duration
• performed_start_at
• performed_end_at
• performed_duration

Isso ocorre porque, neste momento, o agendamento ainda não foi realizado. Esses campos representam informações que só estarão disponíveis após o agendamento e/ou execução da atividade. O que os desenvolvedores devem considerar:

• Não trate esses campos como ausentes: eles estarão presentes no payload, porém com valor null.
• Não utilize valores padrão (como 0 ou datas fictícias) para substituir null.
• Planeje sua integração assumindo que esses campos serão nulos até que o processo de agendamento seja concluído.

ℹ️ Em resumo: sempre espere esses campos com valor null no disparo inicial do webhook.

---

O campo annotations será enviado como null quando o usuário não preencher o campo de observações na plataforma ou quando o agendamento for criado via API comercial sem esse valor, já que o preenchimento não é obrigatório.

Exemplo com campo preenchido:

{
  "annotations": "Próxima dose"
}

ℹ️ Planeje sua integração considerando que o campo estará presente, mas pode ser nulo ou vazio dependendo do comportamento do usuário ou da origem do agendamento.

Este gatilho cancel-appointment é responsável por notificar quando um agendamento é cancelado, o cliente deve indicar a url que deverá ser acionada por esse gatilho, se preferir para distinguir o gatilho dos demais o mesmo poderá receber ao final da url a path /appointment/cancel. Ex: https://www.SeuEndpoint.com/appointment/cancel

No disparo deste webhook, os seguintes campos serão sempre enviados com valor null:

• scheduled_duration
• performed_start_at
• performed_end_at
• performed_duration

Isso ocorre porque, neste momento, o agendamento ainda não foi realizado. Esses campos representam informações que só estarão disponíveis após o agendamento e/ou execução da atividade. O que os desenvolvedores devem considerar:

• Não trate esses campos como ausentes: eles estarão presentes no payload, porém com valor null.
• Não utilize valores padrão (como 0 ou datas fictícias) para substituir null.
• Planeje sua integração assumindo que esses campos serão nulos até que o processo de agendamento seja concluído.

ℹ️ Em resumo: sempre espere esses campos com valor null no disparo inicial do webhook.

---

O campo title será enviado como null somente para agendamentos criados diretamente na plataforma Clinicarx. Agendamentos criados via API comercial podem trazer esse campo preenchido.

Exemplo com campo preenchido:

  {
    "title": "Consulta de acompanhamento"
  }

ℹ️ Planeje sua integração considerando que o campo estará presente, mas pode ser nulo dependendo da origem do agendamento.

---

O campo annotations será enviado como null quando o usuário não preencher o campo de observações na plataforma ou quando o agendamento for criado via API comercial sem esse valor, já que o preenchimento não é obrigatório.

Exemplo com campo preenchido:

{
  "annotations": "Próxima dose"
}

ℹ️ Planeje sua integração considerando que o campo estará presente, mas pode ser nulo ou vazio dependendo do comportamento do usuário ou da origem do agendamento.

No webhook disparado na criação do atendimento, os campos abaixo sempre serão enviados como listas vazias, pois esses dados só podem ser preenchidos durante o atendimento. Eles serão atualizados e enviados apenas nos webhooks de finalização ou cancelamento:

{
  "services": [],
  "rndsInstances": {
    "REL": [],
    "RIA": []
  },
  "clinical_conditions": [],
  "treatments": [],
  "dispensings": [],
  "vaccines": [],
  "rapid_tests": []
}

ℹ️ Planeje sua integração considerando que esses arrays estarão presentes, mas vazios no disparo inicial.

---

Os campos dentro do objeto appointment somente serão preenchidos quando o atendimento iniciado tiver se originado de um agendamento previamente marcado. Caso contrário, eles serão enviados com valor null.

Exemplo quando NÃO há agendamento

  "appointment": {
    "id": null,
    "scheduled_start_at": null,
    "scheduled_end_at": null
  }

ℹ️ Planeje sua integração considerando que o objeto appointment estará presente, mas seus campos podem ser nulos quando não houver agendamento associado.

---

Na criação do atendimento, o campo closed_time sempre será enviado como null, pois o atendimento ainda não foi encerrado/cancelado

Exemplo:

{
  "closed_time": null
}

ℹ️ Planeje sua integração considerando que esse campo só será preenchido após o encerramento do atendimento.

Nos webhooks disparados para finalização ou cancelamento do atendimento, os campos abaixo somente serão preenchidos caso o usuário tenha informado esses dados na plataforma durante o atendimento. Caso contrário, eles serão enviados como null ou listas vazias:

{  
  "services": [],
  "rndsInstances": {
      "REL": [],
      "RIA": []
    },
  "clinical_conditions": [],
  "treatments": [],
  "dispensings": [],
  "vaccines": [],
  "rapid_tests": []
}

ℹ️ Planeje sua integração considerando que esses arrays estarão presentes, mas podem vir nulos ou vazios, pois o preenchimento é opcional e depende da interação do usuário durante o atendimento.

---

Os campos dentro do objeto appointment somente serão preenchidos quando o atendimento iniciado tiver se originado de um agendamento previamente marcado. Caso contrário, eles serão enviados com valor null.

Exemplo quando NÃO há agendamento

  "appointment": {
    "id": null,
    "scheduled_start_at": null,
    "scheduled_end_at": null
  }

ℹ️ Planeje sua integração considerando que o objeto appointment estará presente, mas seus campos podem ser nulos quando não houver agendamento associado.

Nos webhooks disparados para finalização ou cancelamento do atendimento, os campos abaixo somente serão preenchidos caso o usuário tenha informado esses dados na plataforma durante o atendimento. Caso contrário, eles serão enviados como null ou listas vazias:

{  
  "services": [],
  "rndsInstances": {
      "REL": [],
      "RIA": []
    },
  "clinical_conditions": [],
  "treatments": [],
  "dispensings": [],
  "vaccines": [],
  "rapid_tests": []
}

ℹ️ Planeje sua integração considerando que esses arrays estarão presentes, mas podem vir nulos ou vazios, pois o preenchimento é opcional e depende da interação do usuário durante o atendimento.

---

Os campos dentro do objeto appointment somente serão preenchidos quando o atendimento iniciado tiver se originado de um agendamento previamente marcado. Caso contrário, eles serão enviados com valor null.

Exemplo quando NÃO há agendamento

  "appointment": {
    "id": null,
    "scheduled_start_at": null,
    "scheduled_end_at": null
  }

ℹ️ Planeje sua integração considerando que o objeto appointment estará presente, mas seus campos podem ser nulos quando não houver agendamento associado.

Este webhook é disparado antes de qualquer atendimento realizado pelo paciente. Por isso, os seguintes grupos de dados sempre serão enviados como null ou listas vazias neste evento:

• treatments (tratamentos farmacológicos)
• clinical_conditions (condições clínicas)
• dispensings (dispensações)

Por que isso acontece?

Esses dados são gerados apenas após o paciente passar por um atendimento ou procedimento clínico. Como este hook é emitido no momento da criação ou atualização inicial do cadastro, não há histórico clínico associado.

---

O objeto modified_data contém informações sobre a ação realizada no cadastro, incluindo metadados (IP, agente de usuário, data/hora) e um comparativo entre os dados novos e antigos do paciente:

• new_data: representa os dados informados pelo usuário no momento da criação ou edição.
• old_data: representa os dados anteriores à alteração.

Importante:

Este webhook é disparado apenas para novos cadastros. Por isso: O campo old_data sempre será null. O campo new_data será preenchido somente com as informações fornecidas pelo usuário no momento do cadastro (não inclui dados derivados ou calculados posteriormente).

Exemplo prático:

  "modified_data": {
    "edited_data": {
      "subject": "add",
      "new_data": {
        "name": "GUILHERME CARVALHO",
        "email": "guilherme@teste.com.br",
        "document": 65819534077,
        "phone1": "(41) 99999-9999",
        "birthday": "1976-05-13T03:00:00+00:00",
        "civil_name": "PACIENTE TESTE TERCEIRO"
        // demais campos preenchidos pelo usuário
      },
      "old_data": null
    }
  } 

O que isso significa para sua integração?

• Não espere diffs completos entre versões do cadastro neste hook.
• Use new_data para capturar os dados iniciais do paciente.
• Para acompanhar alterações futuras, utilize webhooks específicos para edição.

---

Este webhook é disparado quando ocorre alteração no cadastro do paciente. Ele pode incluir dados clínicos, mas somente se o paciente já tiver passado por algum atendimento. Caso contrário, os seguintes campos continuarão sendo enviados vazios ou como listas nulas:

• treatments (tratamentos farmacológicos)
• clinical_conditions (condições clínicas)
• dispensings (dispensações)

Por que isso acontece?

Esses dados são registrados exclusivamente durante atendimentos ou procedimentos clínicos. Se não houver histórico, esses campos não terão conteúdo.

Exemplo quando não houver dados clínicos:

  "treatments": null,
  "clinical_conditions": null,
  "dispensings": null

---

O objeto modified_data é responsável por indicar quais dados foram alterados no cadastro do paciente. Ele sempre traz:

• new_data: os valores novos informados na edição.
• old_data: os valores anteriores antes da alteração.

Importante:

Diferente do webhook de criação, aqui você terá comparativo completo entre os dados antigos e os novos, permitindo rastrear mudanças com precisão.

O que isso significa para sua integração?

• Use new_data para atualizar seu sistema com os dados mais recentes.
• Utilize old_data para auditoria, histórico ou controle de versões.
• Sempre verifique o campo subject para confirmar que se trata de uma edição ("edit").

Nos webhooks de Novas Clínicas e Edição de Clínicas, o campo service_hours sempre será enviado no payload.

Este campo representa os horários de atendimento online para cada dia da semana, seguindo a ordem:

[ Domingo, Segunda, Terça, Quarta, Quinta, Sexta, Sábado ]

Cada posição do array corresponde a um dia da semana.

Quando um dia estiver indisponível para agendamento online, o valor será null.

Quando disponível, será enviado um objeto com os horários de início e término.

Observação: No exemplo de payload ao lado, Domingo e Sábado estão indisponíveis (null), enquanto os demais dias possuem atendimento das 07:00 às 19:00.

---

Nos webhooks de Novas Clínicas e Edição de Clínicas, o campo modified

Regras de envio

• Campo modified:
  É enviado somente neste gatilho, indicando a data/hora da criação da clínica.

• Campo old_data:
  Sempre será enviado em branco ([]), pois não existe um estado anterior (trata-se da criação).

• Campo new_data:
  Contém todas as informações preenchidas pelo usuário no momento do cadastro da clínica.

  • Campos obrigatórios virão com os valores informados.
  • Campos não obrigatórios poderão ser enviados como null caso não tenham sido preenchidos.

Nos webhooks de Novas Clínicas e Edição de Clínicas, o campo service_hours sempre será enviado no payload.

Este campo representa os horários de atendimento online para cada dia da semana, seguindo a ordem:

[ Domingo, Segunda, Terça, Quarta, Quinta, Sexta, Sábado ]

Cada posição do array corresponde a um dia da semana.

Quando um dia estiver indisponível para agendamento online, o valor será null.

Quando disponível, será enviado um objeto com os horários de início e término.

Observação: No exemplo de payload ao lado, Domingo e Sábado estão indisponíveis (null), enquanto os demais dias possuem atendimento das 07:00 às 19:00.

---

Nos webhooks de Novas Clínicas e Edição de Clínicas, o campo modified

Regras de envio

• Campo modified:
  É enviado somente neste gatilho, indicando a data/hora da criação da clínica.

• Campo old_data:
  Sempre será enviado em branco ([]), pois não existe um estado anterior (trata-se da criação).

• Campo new_data:
  Contém todas as informações preenchidas pelo usuário no momento do cadastro da clínica.

  • Campos obrigatórios virão com os valores informados.
  • Campos não obrigatórios poderão ser enviados como null caso não tenham sido preenchidos.

Este gatilho new-user é responsável por notificar novos usuários, o cliente deve indicar a url que deverá ser acionada por esse gatilho, se preferir para distinguir o gatilho dos demais o mesmo poderá receber ao final da url a path /user/new. Ex: https://www.SeuEndpoint.com/user/new.

Este gatilho edit-user é responsável por notificar quando um usuário é alterado/editado, o cliente deve indicar a url que deverá ser acionada por esse gatilho, se preferir para distinguir o gatilho dos demais o mesmo poderá receber ao final da url a path /user/edit. Ex: https://www.SeuEndpoint.com/user/edit.

Este gatilho new-service é responsável por notificar novos serviços, o cliente deve indicar a url que deverá ser acionada por esse gatilho, se preferir para distinguir o gatilho dos demais o mesmo poderá receber ao final da url a path /service/new. Ex: https://www.SeuEndpoint.com/service/new

Este gatilho edit-service é responsável por notificar quando um serviço é alterado/editado, o cliente deve indicar a url que deverá ser acionada por esse gatilho, se preferir para distinguir o gatilho dos demais o mesmo poderá receber ao final da url a path /service/edit. Ex: https://www.SeuEndpoint.com/service/edit