API Inbox. 1.5

Versão atualizada da API do Inbox. Por gentileza atualizar para essa versão.

#API do DT Ticket (v1.5)

Endereço base

Todos os endereços referenciados neste documento tem como base a seguinte URL:

https://api.directtalk.com.br/1.5/ticket

A API do Ticket é servida somente sob HTTPS. Para garantir a privacidade das informações, HTTP não criptografado não é suportado.

Autenticação/Autorização

A Hi Platform irá fornecer um usuário e uma senha de acesso exclusivo
para o uso da API. Saiba mais.
A autenticação da API será feita utilizando o protocolo Basic.

Vamos descrever brevemente o como autenticar usando o protocolo Basic.

Considere hipoteticamente que o usuário da API passado é usuarioApi e a senha é senhaApi.

Primeiro, calcule um token da seguinte forma:

• Concatene o usuário e a senha separado por :. No nosso exemplo usuarioApi:senhaApi;
• Codifique o resultado acima utilizando o formato Base64. No nosso exemplo o exemplo o resultado (token) dessa operação é dXN1YXJpb0FwaTpzZW5oYUFwaQ==.

O token deve ser passado em todas as requisições através do header HTTP Authorization. O valor do header é a junção do esquema de autenticação (no caso Basic) com o token previamente enviado, separados por um espaço em branco. Exemplo:

Authorization: Basic dXN1YXJpb0FwaTpzZW5oYUFwaQ==

Caso o token de autenticação seja inválido, o acesso será negado e um status code HTTP 401 (Unauthorized) será devolvido. Caso, tente acessar com um usuário e senha válidos da Hi Platform, mas que não seja um usuário da API o acesso será negado e um status code HTTP 403 (Forbidden) será devolvido.

Cabeçalhos comuns a todas as operações

As requisições para a API do Ticket devem possuir os seguintes cabeçalhos:

Cotas de consumo

O cliente que usar essa API estará sujeito a um limite na quantidade de requisições que poderá enviar em um dado período de tempo. Essa prática é conhecida como Rate Limiting e é utilizada para garantir a qualidade do serviço.

A cada 'X' minutos (variável conforme o escopo solicitado) o cliente tem direito a fazer um determinado número de requisições (também variável conforme o escopo). Passado o tempo especificado, o limite é reiniciado.

O consumo do limite pode variar conforme o escopo e deve ser acompanhado pelos seguintes http headers:

• X-Rate-Limit-Limit: informa o total de requisições permitidas dentro de uma janela de X minutos.
• X-Rate-Limit-Remaining: informa quantas requisições para API ainda são permitidas dentro da janela de X minutos corrente. Se uma requisição for feita após esse valor retornar 0, a API retornará o HTTP status code 429 (Too many connections.).
• X-Rate-Limit-Reset: devolve o número de segundos disponíveis na janela atual.

Escopos de rate limiting

Importante: Certifique-se de checar o escopo de rate limiting no resumo de cada operação.

Paginação

Determinadas operações podem potencialmente retornar muitos registros. Nestes casos os resultados serão sempre paginados e os seguintes parâmetros opcionais são suportados através de query string:

• pageNumber: Número da página desejada. Se esse parâmetro não for passado ou for maior do que a quantidade de páginas disponíveis, será assumido que a busca é da página 1;
• pageSize: Quantidade máxima de registros por página. Deve ser um número entre 10 e 1000. Se esse parâmetro não for passado, será assumido o valor 1000;

Para auxiliar na navegação nos resultados retornados, as operações que requerem paginação devolverão os seguintes cabeçalhos HTTP:

X-Pagination-TotalResult: Total de resultados.
X-Pagination-TotalPages: Total de páginas.
Link: <https://api.directtalk.com.br/1.5/ticket/...\>; rel="First", 
      <https://api.directtalk.com.br/1.5/ticket/...\>; rel="Previous", 
      <https://api.directtalk.com.br/1.5/ticket/...\>; rel="Next", 
      <https://api.directtalk.com.br/1.5/ticket/...\>; rel="Last"

É importante notar que a existência dos links está sujeita ao contexto atual. Por exemplo: se a página atual for a primeira, então o link Previous não estará disponível.

Importante: Certifique-se de checar a paginação no resumo de cada operação.

Retornos comuns para todas as operações em caso de erro

##### Cabeçalhos

##### Códigos HTTP

##### Corpo

	{
		"messages": [
						"descrição do erro",
						"descrição do erro",
						"..."
					]
	}

# Sobre o formato de datas
Nessa API, a fim de evitar problemas com formatos de campos do tipo Data (via parâmetro de requisição ou em payloads das requisições), convencionou-se utilizar o formato de data conhecido como EPOCH ou Unix Time (https://en.wikipedia.org/wiki/Unix_time), onde a data é representada por uma sequência numérica.

# Mudanças da versão

Histórico de mudanças que foram realizadas na v1.5

# Sub-Recursos

Departamentos

• GET /departments [(listar departamentos ativos)]

Grupos

• GET /groups (listar grupos ativos)

Tipos

• GET /types (listar tipos ativos)

Estados

• GET /states (listar estados)

Usuários

• GET /users (filtrar usuários)

Contas de email cadastradas

• GET /mailaccounts (listar contas email)

Campos Customizados

• GET /customforms (obter campos customizados)

Tickets

• POST /tickets (criar um novo ticket)
• POST /tickets/mail (criar um novo ticket por email)
• PUT /tickets/{id} (alterar um ticket)
• POST /tickets/{id}/identifications (inserir identificações)
• PATCH /tickets/{id}?state=close (fechar um ticket)
• PATCH /tickets/{id}?state=reopen (reabrir um ticket)
• GET /tickets (filtrar tickets)
• GET /tickets/search (buscar tickets)
• GET /tickets/{id} (consultar um ticket)
• GET /tickets/{id}/classifications (consultar as classificações de um ticket)
• GET /tickets/{id}/forms (consultar as respostas de campos customizados de um ticket)

Alterações

• GET /tickets/{id}/changes (listar alterações do ticket)

Comentários

• POST /tickets/{id}/comments (adicionar um comentário em um ticket)
• GET /tickets/{id}/comments (listar comentários de um ticket)
• GET /tickets/{id}/comments/public (listar comentários públicos de um ticket)
• GET /tickets/{id}/comments/private (listar comentários privados de um ticket)

Anexos

• POST /tickets/{id}/attachments (adicionar um anexo em um ticket)
• GET /tickets/{id}/attachments (listar anexos de um ticket)
• GET /tickets/{id}/attachments/public (listar anexos públicos de um ticket)
• GET /tickets/{id}/attachments/private (listar anexos privados de um ticket)
• GET /tickets/{id}/attachments/{attachmentId}/content (baixar um anexo de um ticket)

Monitoramento

• GET /ticket/monitoring/groups (monitoria de tickets por grupos)
• GET /ticket/monitoring/states (monitoria de tickets por estados)
• GET /ticket/monitoring/types (monitoria de tickets por tipos)
• GET /ticket/monitoring/volumetry (monitoria de tickets por volumetria)

Webhook

Entregando os dados

• Por questões de segurança, os clientes do webhook receberão via POST um “id do payload” que lhes permitirá realizar uma chamada autenticada na operação /webhook/payloads/{id}, para recuperar o payload específico.

Algumas observações

• O POST do lado do cliente deve suportar application/json;
• O POST do lado do cliente não deve ser autenticado;
• O POST do lado do cliente deve responder em até 500 milisegundos;
• Um id de payload “vive” apenas durante 24 horas ou até que seja recuperado;

Webhook Endpoints

• POST /webhooks (Criar uma nova assinatura)
• GET /webhooks (Listar as assinaturas)
• GET /webhooks/?type=create (Listar as assinaturas de um tipo específico)
• GET /webhooks/?type=update (Listar as assinaturas de um tipo específico)
• GET /webhooks/{id} (listar os detalhes de uma assinatura)
• PUT /webhooks/{id} (Atualizar uma assinatura existente)
• DELETE /webhooks/delete/{id} (Excluir uma assinatura existente)
• GET /webhooks/{id}/logs (Retornar os eventos de uma determinada assinatura)
• GET /webhooks/payloads/{id} (Retornar um payload específico)

Webhook - Listar as assinaturas de um tipo específico

# Listar departamentos ativos

Retorna os departamentos ativos para a operação que possui o produto Inbox configurado

##### Resumo

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id":"...",
			 	"name":"..."
			},
			...
		]
	}

Voltar para os sub-recursos afetados

# Listar grupos ativos

Retorna os grupos ativos para a operação

##### Resumo

REQUISIÇÃO

##### Parâmetros obrigatórios (caso operação possua departamentos, caso contrário não precisa ser informado)

• departmentId: Id do departamento, lista todos os grupos associados a esse departamento.

##### Formato

• O departmentId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id":"...",
			 	"name":"..."
			},
			...
		]
	}

Voltar para todos os Sub-Recursos

# Listar tipos ativos

Retorna os tipos ativos existentes para a operação

##### Resumo

REQUISIÇÃO

##### Parâmetros obrigatórios (caso operação possua departamentos, caso contrário não precisa ser informado)

• departmentId: Id do departamento, lista todos os grupos associados a esse departamento.

##### Formato

• O departmentId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id":"...",
			 	"name":"..."
			},
			...
		]
	}

Voltar para todos os sub-recursos

# Listar estados

Retorna os possíveis estados para os tickets existentes

##### Resumo

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id":"...",
			 	"name":"..."
			},
			...
		]
	}

Voltar para todos os sub-recursos

# Filtrar usuários

Lista os usuários ativos para a operação, habilitados no Inbox.
Essa requisição permite também filtrar usuários com acessos a grupos (quando o vínculo é feito através da plataforma Supervisor)

##### Resumo

REQUISIÇÃO

##### Parâmetros obrigatórios (caso operação possua departamentos, caso contrário não precisa ser informado)

• departmentId: Id do departamento, lista todas as contas de email associados a esse departamento.

##### Parâmetros opcionais

• groupId: Id do grupo, quando informado, lista todos os usuários associados ao grupo.

##### Formato

• O departmentId informado deve ser um GUID válido.
• O groupId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id":"...",
			 	"name":"..."
			},
			...
		]
	}

Voltar para todos os sub-recursos

# Listar Contas Email

Lista as contas de email associadas ao Inbox para a operação.

##### Resumo

REQUISIÇÃO

##### Parâmetros obrigatórios (caso operação possua departamentos, caso contrário não precisa ser informado)

• departmentId: Id do departamento, lista todas as contas de email associados a esse departamento.

##### Parâmetros opcionais

• includeInactives: Quando informado como true, retorna também as contas que estão inativas

##### Formato

• O departmentId informado deve ser um GUID válido.
• O includeInactives informado deve ser um boolean válido.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id": "...",
				"accountAddress": "...",
				"accountName": "...",
				"group": {
							"id": "...",
							"name": "..."
						},
				"type": {
							"id": "...",
							"name": "..."
						},
				"active": "..."
			},
			...
		]
	}

Voltar para todos os sub-recursos

# Obter Campos Customizados

Retorna os campos do formulário padrão para a operação/departamento.
Esses campos podem ser usados nas chamadas de criação de ticket, de inserir identificações e ao filtrar tickets.

##### Resumo

REQUISIÇÃO

##### Parâmetros obrigatórios (caso operação possua departamentos, caso contrário não precisa ser informado)

• departmentId: Id do departamento

##### Formato

• Quando informado, o departmentId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"name": "...",
				"description": "...",
				"required": "..."				
			},
			...
		]
	}

Voltar para todos os sub-recursos

# Criar um novo ticket

##### Resumo

REQUISIÇÃO

##### Corpo

{
	"creator": "...",
	"subject": "...",
	"description": "...",
	"type": "...",
	"group": "...",
	"state": "...",
	"deadline": 1,
	"responsible":"...",
	"externaldata": [
						{
							"datatype":0,
							"key":"...",
							"value":"..."
						}
					],
	"identifications": [
						{
							"key":"...",
							"value":"..."
						}
					]
}

• creator: Identificador do usuário que está criando o ticket.
• subject: Assunto.
• description: Descrição.
• type: Identificador do tipo.
• group: Identificador do grupo.
• state: Identificador estado.
• deadline: (opcional) Data correspondente ao prazo, no formato epoch. Quando não informada, o prazo será determinado pelo tipo.
• responsible: (opcional) Identificador do usuário que é responsável pelo ticket.
• externaldata: (opcional) Informações adicionais que serão incluídas no ticket.
• datatype: Identificador do tipo de informação. Trataremos os tipos 0 - Email, 1 - ConsumerName, 2 - Bot e 3 - GenericIdentification
  • key: Chave da informação que será incluída
  • value: Valor da informação que será incluída.
• identifications: (opcional) Chaves de identificação - devem coincidir com os campos customizados da operação (para saber os campos possíveis, usar a chamada /customforms).
  • key: nome do campo do formulário de campos customizados (Variavel do campo)
  • value: Valor da informação que será incluída.

##### Formato

• O usuário criador deve ser informado e existir.
• O assunto deve ser informado e ter até 200 caracteres.
• A descrição deve ser informada e ter até 1600 caracteres.
• O tipo deve ser informado e existir.
• O grupo deve ser informado e existir.
• O estado deve ser informado e existir.
• O estado não deve fechar o ticket.
• O prazo (quando informado) deve ser válido.
• O usuário responsável (quando informado) deve existir.
• O usuário responsável (quando informado) deve fazer parte do grupo.
• Identifications: se o nome do campo não coincidir com os campos do formulário customizado (Variavel do campo) a informação será descartada.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		"ticketId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX"
	}

Voltar para todos os sub-recursos

# Criar um novo ticket por email

##### Resumo

REQUISIÇÃO

##### Corpo

{
	"subject": "...",
	"description": "...",
	"type": "...",
	"group": "...",
	"state": "...",
	"deadline": 1,
	"responsible":"...",
	"emailConsumer": "...",
	"nameConsumer": "...",
	"accountMail": "...",
	"identifications": 
					[
						{
							"key":"...",
							"value":"..."
						}
					]
	"CC": 
					[
						{
							"...","...",...,"..."
							
						}
					]
	"CCO": 
					[
						{							
							"...","...",...,"..."
						}
					]
}

• subject: Assunto.
• description: Descrição.
• type: Identificador do tipo.
• group: Identificador do grupo.
• state: Identificador estado.
• deadline: (opcional) Data correspondente ao prazo, no formato epoch. Quando não informada, o prazo será determinado pelo tipo.
• responsible: (opcional) Identificador do usuário que é responsável pelo ticket.
• emailConsumer: email do consumidor.
• nameConsumer: nome do consumidor.
• accountMail: Identificador da conta de email que deverá ser utilizada para enviar as mensagens para o consumidor.
• identifications: (opcional) Chaves de identificação - devem coincidir com os campos customizados da operação (para saber os campos possíveis, usar a chamada /customforms).
  • key: Nome do campo do formulário de campos customizados (Variável do campo)
  • value: Valor da informação que será incluída.
• CC: lista de emails para serem adicionados como cópia.
• CCO: lista de emails para serem adicionados cópia oculta.

##### Formato

• O assunto deve ser informado e ter até 200 caracteres.
• A descrição deve ser informada e ter até 1600 caracteres.
• O tipo deve ser informado e existir.
• O grupo deve ser informado e existir.
• O estado deve ser informado e existir.
• O estado não deve fechar o ticket.
• O prazo (quando informado) deve ser válido.
• O usuário responsável (quando informado) deve existir.
• O usuário responsável (quando informado) deve fazer parte do grupo.
• Identifications: se o nome do campo não coincidir com os campos do formulário customizado (Variável do campo) a informação será descartada.
• CC e CCO: Os emails devem seguir os padroes RFC 5322 e RFC 5321

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		"ticketId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX"
	}

Voltar para todos os sub-recursos

# Alterar um ticket

##### Resumo

REQUISIÇÃO

##### Corpo

{
	"user": "...",
	"subject": "...",
	"description": "...",
	"type": "...",
	"group": "...",
	"state": "...",
	"deadline": 1,
	"responsible":"..."
}

• user: Identificador do usuário que está alterando o ticket.
• subject: Assunto.
• description: Descrição.
• type: Identificador do tipo.
• group: Identificador do grupo.
• state: Identificador estado.
• deadline: (opcional) Data correspondente ao prazo, no formato epoch.
• responsible: (opcional) Identificador do usuário que é responsável pelo ticket.

##### Formato

• O usuário da alteração deve ser informado e existir.
• O assunto deve ser informado e ter até 200 caracteres.
• A descrição deve ser informada e ter até 1600 caracteres.
• O tipo deve ser informado e existir.
• O grupo deve ser informado e existir.
• O estado deve ser informado e existir.
• O estado não deve encerrar o ticket.
• O prazo (quando informado) deve ser válido.
• O usuário responsável (quando informado) deve existir.
• O usuário responsável (quando informado) deve fazer parte do grupo.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

Voltar para todos os sub-recursos

# Inserir identificações

##### Resumo

Observação: É através desta requisição que sao realizadas alterações nos formulários do Inbox, logo deve ser realizada apenas após a criação do ticket.

REQUISIÇÃO

##### Parâmetros opcionais

• scopeId: Id do tipo (se o tipo for informado, o formulário alterado será o formulario do tipo e não o padrão)

##### Corpo

{
	"user": "...",
	"identifications": 
		[
			{
				"key":"...",
				"value":"..."
			}
		]
}

• user: Identificador do usuário que está alterando o ticket.
• identifications: Chaves de identificação - devem coincidir com os campos customizados da operação (para saber os campos possíveis, usar a chamada /customforms).
  • key: Nome do campo do formulário de campos customizados (Variável do campo)
  • value: Valor da informação que será incluída.

##### Formato

• O usuário da alteração deve ser informado e existir.
• identifications deve ser informado
• O id do tipo quando informado, deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

				    ocorreu erro ao salvar o formulário, nesse caso o objeto de retorno trará as mensagens)

##### Corpo em caso de erro

	{
		"messages": "..."
	}

##### Cabeçalhos em caso de sucesso

Voltar para todos os sub-recursos

# Fechar um ticket

##### Resumo

REQUISIÇÃO

##### Corpo

{
	"user": "..."
}

• user: Identificação do usuário que está fechando o ticket.

##### Formato

• O usuário deve ser informado e existir.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

Voltar para todos os sub-recursos

# Reabrir um ticket

##### Resumo

REQUISIÇÃO

##### Corpo

{
	"user": "..."
}

• user: Identificação do usuário que está reabrindo o ticket.

##### Formato

• O usuário deve ser informado e existir.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

Voltar para todos os sub-recursos

# Filtrar tickets

##### Resumo

REQUISIÇÃO

##### Parâmetros obrigatórios (caso operação possua departamentos, caso contrário não precisa ser informado)

• departmentId: Id do departamento, lista tickets associados a esse departamento.

##### Parâmetros opcionais

• userId: Identificador do usuário. Quando informado, considera o escopo do usuário para localizar um ticket.
• groupId: Identificador do grupo. Se houver mais de um, deve ser separado por vírgula.
• typeId: Identificador do tipo. Se houver mais de um, deve ser separado por vírgula.
• stateId: Identificador do estado. Se houver mais de um, deve ser separado por vírgula.
• responsibleId: Identificador do usuário responsável. Se houver mais de um, deve ser separado por vírgula.
• creatorId: Identificador do usuário criador. Se houver mais de um, deve ser separado por vírgula.
• startDate: Data/hora inicial para busca, no formato epoch.
• endDate: Data/hora final para busca, no formato epoch.
• dateInfo: Parâmetro que informa sobre qual data o intervalo definido pelos parâmetros startDate e endDate dizem respeito. Esse parâmetro suporta duas opções:
  • createDate (padrão)
  • endDate
• sort: Informação pela qual se deseja ordenar o resultado:
  • number (padrão quando não informado)
  • subject
  • deadline
• desc: Quando informado, ordena de forma decrescente.
• externaldata: quando informado busca por tickets que tenham as chaves externas conforme informado. Deverá ser informado qual chave e seu valor separados por | (pipe). Se houver mais de um, deve ser separado por ponto e vírgula. Chaves que podem ser consultadas: email e receipt. Exemplo: email|teste@directtalk.com.br;receipt|0D9I8R7E6C
• customformsdata: quando informado busca por tickets que tenham os dados de identificação informados. Deverá ser informado qual chave e seu valor separados por | (pipe). Se houver mais de um, deve ser separado por ponto e vírgula. Para saber quais chaves podem ser utilizadas, usar a chamada /customforms (valor do campo name).

##### Formato

• O departmentId informado deve ser um GUID válido.
• O userId informado deve ser um GUID válido.
• O(s) groupId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) typeId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) stateId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) responsibleId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) creatorId informado(s) deve(m) ser GUID(s) válido(s).
• O valor informado para deadline deve estar entre os valores suportados.
• O valor informado para sort deve estar entre os valores suportados.
• O período informado por startDate e endDate deve ser válido.
• O período informado deve ter no máximo 31 dias.
• dateInfo só deve ser informado quando houver um período.
• O valor informado para dateInfo deve estar entre os valores suportados.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id":"...",
				"number": "...",
			 	"subject":"...",
				"description": "...",
				"type": {
							"id":"...",
							"name":"..."
						},
				"group": {
							"id":"...",
							"name":"..."
						},
				"state": {
							"id":"...",
							"name":"..."
						},
				"deadline": 1,
				"reopenDate": 1,
				"responsible":	{
									"id":"...",
									"name":"..."
								},
				"creationDate": "...",
				"creationUser":	{
									"id":"...",
									"name":"..."
								},
				"lastChangeUser":{
									"id":"...",
									"name":"..."
								},
				"endDate": 1,
				"lastChangeDate": 1,
				"formAnswers":	[
								{
									"question":"...",
									"answer":"...",
                                    "defaultForm": true/false,
								}
                            ]
            },
			...
		]
	}

• id: GUID que representa o identificador do ticket.
• number: Número do ticket (gerado automaticamente para facilitar localização).
• subject: Assunto.
• description: Descrição.
• type: Tipo.
• group: Grupo.
• state: Estado.
• deadline: Prazo, no formato epoch.
• reopenDate: Data de reabertura, no formato epoch.
• responsible: (pode ser nulo) Responsável.
• creationDate: Data de criação, no formato epoch.
• creationUser: Usuário que criou o ticket.
• endDate: (pode ser nulo) Data de encerramento, no formato epoch.
• lastChangeUser: Usuário que fez a ultima alterção no ticket.
• lastChangeDate: Data da ultima alteração, no formato epoch.
• • formAnswers: Respostas dos campos customizados, no mesmo formato do recurso: Consultar as respostas de campos customizados de um ticket

Voltar para todos os sub-recursos

# Buscar tickets

##### Resumo

REQUISIÇÃO

##### Parâmetros obrigatórios (caso operação possua departamentos, caso contrário não precisa ser informado)

• departmentId: Id do departamento, lista tickets associados a esse departamento.

##### Parâmetros obrigatórios

• text: Valor a ser buscado. A pesquisa é efetuada no campo assunto e na descrição. Pode ser informado um endereço de email (para busca pelo cliente), ou até um texto entre aspas (") para busca exata do texto.

##### Parâmetros opcionais

• userId: Identificador do usuário. Quando informado, considera o escopo do usuário para localizar um ticket.

##### Formato

• O departmentId informado deve ser um GUID válido.
• O userId informado deve ser um GUID válido.
• O text a ser buscado deve ser preenchido e ter mais de 3 caracteres.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id":"...",
				"number": "...",
			 	"subject":"...",
				"description": "...",
				"type": {
							"id":"...",
							"name":"..."
						},
				"group": {
							"id":"...",
							"name":"..."
						},
				"state": {
							"id":"...",
							"name":"..."
						},
				"deadline": 1,
				"reopenDate": 1,
				"responsible":	{
									"id":"...",
									"name":"..."
								},
				"creationDate": "...",
				"creationUser":	{
									"id":"...",
									"name":"..."
								},
				"lastChangeUser":{
									"id":"...",
									"name":"..."
								},
				"endDate": 1,
				"lastChangeDate": 1
			},
			...
		]
	}

• id: GUID que representa o identificador do ticket.
• number: Número do ticket (gerado automaticamente para facilitar localização).
• subject: Assunto.
• description: Descrição.
• type: Tipo.
• group: Grupo.
• state: Estado.
• deadline: Prazo, no formato epoch.
• reopenDate: Data de reabertura, no formato epoch.
• responsible: (pode ser nulo) Responsável.
• creationDate: Data de criação, no formato epoch.
• creationUser: Usuário que criou o ticket.
• endDate: (pode ser nulo) Data de encerramento, no formato epoch.
• lastChangeUser: Usuário que fez a ultima alterção no ticket.
• lastChangeDate: Data da ultima alteração, no formato epoch.

Voltar para todos os sub-recursos

# Consultar um ticket

##### Resumo

REQUISIÇÃO

##### Parâmetros opcionais

• userId: Identificador do usuário. Quando informado, considera o escopo do usuário para localizar um ticket.

##### Formato

• O userId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		"id":"...",
		"number": "...",
	 	"subject":"...",
		"description": "...",
		"type": {
					"id":"...",
					"name":"..."
				},
		"group": {
					"id":"...",
					"name":"..."
				},
		"state": {
					"id":"...",
					"name":"..."
				},
		"deadline": 1,
		"reopenDate":1,
		"responsible":	{
							"id":"...",
							"name":"..."
						},
		"creationDate": "...",
		"creationUser": {
						"id":"...",
						"name":"..."
					  },
		"lastChangeUser":{
							"id":"...",
							"name":"..."
						},
		"endDate": 1,
		"lastChangeDate": 1
	}

• id: GUID que representa o identificador do ticket.
• number: Número do ticket (gerado automaticamente para facilitar localização).
• subject: Assunto.
• description: Descrição.
• type: Tipo.
• group: Grupo.
• state: Estado.
• deadline: Prazo, no formato epoch.
• reopenDate: Data de reabertura, no formato epoch.
• responsible: (pode ser nulo) Responsável.
• creationDate: Data de criação, no formato epoch.
• creationUser: Usuário que criou o ticket.
• endDate: (pode ser nulo) Data de encerramento, no formato epoch.
• lastChangeUser: Usuário que fez a ultima alterção no ticket.
• lastChangeDate: Data da ultima alteração, no formato epoch.

Voltar para todos os sub-recursos

# Consultar as classificações de um ticket

##### Resumo

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	[
		"...",
		"...",
		"..."
	]

Voltar para todos os sub-recursos

# Consultar as respostas de campos customizados de um ticket

##### Resumo

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	[
		{
			"question": "...",
			"answer": "...",
			"defaultForm": true/false,
		},
		{
			"question": "...",
			"answer": "...",
			"defaultForm": true/false,
		}
	]

• question: String Campo que descreve pergunta do formulário.
• answer: String Resposta do formulário.
• defaultForm: True/False Identifica a qual tipo de formulário a pergunta faz parte (true - identifica formulário padrão e false: formulário por tipo)
  Voltar para todos os sub-recursos

# Listar alterações do ticket

##### Resumo

REQUISIÇÃO

##### Parâmetros opcionais

• userId: Identificador do usuário. Quando informado, considera o escopo do usuário para localizar um ticket.

##### Formato

• O userId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id": "...",
				"date": 1,
				"user": {
							"id":"...",
							"name":"..."
						},
				"details":	[
								{
									"information":"...",
									"value":"..."
								},
								...
							]
				},
				...
		]
	}

• id: GUID que representa o identificador do conjunto de alterações.
• date: Data do conjunto de alterações, no formato epoch.
• user: Usuário que efetuou as alterações.
• details: Lista com ao menos uma alteração:
  • information: Informação alterada.
  • oldValue: Valor antes da alteração.

Voltar para todos os sub-recursos

# Adicionar um comentário em um ticket

##### Resumo

REQUISIÇÃO

##### Corpo

{
	"creator": "...",
	"content": "...",
	"public": true,
	"mailAccountSenderId": "..."
}

• creator: Identificador do usuário que fez o comentário.
• content: Comentário.
• public: Identifica se o comentário é público (true) ou privado (false).
• mailAccountSenderId: (opcional) Identificador da conta (email) de sáida, caso comentário público.

##### Formato

• O usuário criador deve ser informado e existir.
• O comentário deve ser informado e ter até 2000 caracteres.
• O identificador da conta (email) de sáida deve ser um GUID existente e válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

Voltar para todos os sub-recursos

# Listar comentários de um ticket

##### Resumo

REQUISIÇÃO

##### Parâmetros opcionais

• userId: Identificador do usuário. Quando informado, considera o escopo do usuário para localizar um ticket.

##### Formato

• O userId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id":"...",
				"date": 1,
				"user": {
							"id":"...",
							"name":"..."
						},
			 	"content":"..."
				"public": true
			},
			...
		]
	}

• id: GUID que representa o identificador do comentário.
• date: Data do comentário, no formato epoch.
• user: Usuário que efetuou o comentário.
• content: Comentário propriamente dito.
• public: Identifica se o comentário é publico (true) ou privado (false)

Voltar para todos os sub-recursos

# Listar comentários públicos de um ticket

##### Resumo

REQUISIÇÃO

##### Parâmetros opcionais

• userId: Identificador do usuário. Quando informado, considera o escopo do usuário para localizar um ticket.

##### Formato

• O userId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id":"...",
				"date": 1,
				"user": {
							"id":"...",
							"name":"..."
						},
			 	"content":"..."
				"public": true
			},
			...
		]
	}

• id: GUID que representa o identificador do comentário.
• date: Data do comentário, no formato epoch.
• user: Usuário que efetuou o comentário.
• content: Comentário propriamente dito.
• public: Identifica se o comentário é publico (true) ou privado (false)

Voltar para todos os sub-recursos

# Listar comentários privados de um ticket

##### Resumo

REQUISIÇÃO

##### Parâmetros opcionais

• userId: Identificador do usuário. Quando informado, considera o escopo do usuário para localizar um ticket.

##### Formato

• O userId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
			{
				"id":"...",
				"date": 1,
				"user": {
							"id":"...",
							"name":"..."
						},
			 	"content":"..."
				"public": true
			},
			...
		]
	}

• id: GUID que representa o identificador do comentário.
• date: Data do comentário, no formato epoch.
• user: Usuário que efetuou o comentário.
• content: Comentário propriamente dito.
• public: Identifica se o comentário é publico (true) ou privado (false)

Voltar para todos os sub-recursos

# Adicionar um anexo em um ticket

##### Resumo

REQUISIÇÃO

O arquivo deve estabelecer seu nome e tipo no "part" (vide RFC-1867). Preferencialmente deve ser codificado em base64 para a transferência - nesse caso, a informação também é adicionada ao "part" (vide RFC1521). Ex.:

#!
--Boundary_XXXXXXXXX
Content-Transfer-Encoding: BASE64
Content-Type: text/plain
Content-Disposition: form-data; filename="nome do arquivo.txt"; name="file"

SXNzbyDDqSB1bSB0ZXN0ZS4=
--Boundary_XXXXXXXXX--

##### Parâmetros

• userId: Identificador do usuário que está adicionando o anexo.
• publicAttach: Identifica se o anexo é publico (true) ou privado (false)

##### Formato

• O userId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

Voltar para todos os sub-recursos

# Listar anexos de um ticket

##### Resumo

REQUISIÇÃO

##### Parâmetros opcionais

• userId: Identificador do usuário. Quando informado, considera o escopo do usuário para localizar um ticket.

##### Formato

• O userId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
		    {
		      "id": "...",
		      "name": "...",
		      "url": "...",
		      "mimeType": "...",
		      "length": 1,
		      "humanReadableLength": "...",
			  "public": ...
		    },
			...
    	]
	}

• id: GUID que representa o identificador do anexo.
• name: Nome do arquivo.
• url: URL para baixar o anexo.
• mimeType: Mime type correspondente ao tipo do arquivo.
• length: Tamanho do arquivo em bytes.
• humanReadableLength: Tamanho do arquivo tratado para facilitar a leitura.
• public: Identifica se o anexo é publico (true) ou privado (false)

Voltar para todos os sub-recursos

# Listar anexos públicos de um ticket

##### Resumo

REQUISIÇÃO

##### Parâmetros opcionais

• userId: Identificador do usuário. Quando informado, considera o escopo do usuário para localizar um ticket.

##### Formato

• O userId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
		    {
		      "id": "...",
		      "name": "...",
		      "url": "...",
		      "mimeType": "...",
		      "length": 1,
		      "humanReadableLength": "...",
			  "public": ...
		    },
			...
    	]
	}

• id: GUID que representa o identificador do anexo.
• name: Nome do arquivo.
• url: URL para baixar o anexo.
• mimeType: Mime type correspondente ao tipo do arquivo.
• length: Tamanho do arquivo em bytes.
• humanReadableLength: Tamanho do arquivo tratado para facilitar a leitura.
• public: Identifica se o anexo é publico (true) ou privado (false)

Voltar para todos os sub-recursos

# Listar anexos privados de um ticket

##### Resumo

REQUISIÇÃO

##### Parâmetros opcionais

• userId: Identificador do usuário. Quando informado, considera o escopo do usuário para localizar um ticket.

##### Formato

• O userId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		[
		    {
		      "id": "...",
		      "name": "...",
		      "url": "...",
		      "mimeType": "...",
		      "length": 1,
		      "humanReadableLength": "...",
			  "public": ...
		    },
			...
    	]
	}

• id: GUID que representa o identificador do anexo.
• name: Nome do arquivo.
• url: URL para baixar o anexo.
• mimeType: Mime type correspondente ao tipo do arquivo.
• length: Tamanho do arquivo em bytes.
• humanReadableLength: Tamanho do arquivo tratado para facilitar a leitura.
• public: Identifica se o anexo é publico (true) ou privado (false)

Voltar para todos os sub-recursos

# Baixar um anexo de um ticket

##### Resumo

REQUISIÇÃO

##### Parâmetros opcionais

• userId: Identificador do usuário. Quando informado, considera o escopo do usuário para localizar um ticket.

##### Formato

• O userId informado deve ser um GUID válido.

RESPOSTA

##### Cabeçalhos em caso de erro (além dos comuns a todas as operações)

##### Cabeçalhos em caso de sucesso

Voltar para todos os sub-recursos

# Monitoria de tickets por grupos

Consulta de tickets de forma sumarizada, por grupo, levando em consideração os parâmetros informados

##### Resumo

REQUISIÇÃO

##### Parâmetros obrigatórios (caso operação possua departamentos, caso contrário não precisa ser informado)

• departmentId: Id do departamento, lista todas a monitoria de tickets por grupos associados a esse departamento.

##### Parâmetros opcionais

• groupId: Identificador do grupo. Se houver mais de um, deve ser separado por vírgula.
• typeId: Identificador do tipo. Se houver mais de um, deve ser separado por vírgula.
• stateId: Identificador do estado. Se houver mais de um, deve ser separado por vírgula.
• startDate: Data/hora inicial para busca, no formato epoch.
• endDate: Data/hora final para busca, no formato epoch.

##### Formato

• O departmentId informado deve ser um GUID válido.
• O(s) groupId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) typeId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) stateId informado(s) deve(m) ser GUID(s) válido(s).
• O período informado por startDate e endDate deve ser válido.
• O período informado deve ter no máximo 31 dias.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	[
	    {
	        "groupId": "...",
	        "groupName": "...",
	        "value": 1
	    },
    	   ...
]

• groupId: GUID que representa o identificador do grupo.
• groupName: Nome do Grupo.
• value: Quantidade de tickets.

Voltar para todos os sub-recursos

# Monitoria de tickets por estados

Consulta de tickets de forma sumarizada, por estado, levando em consideração os parâmetros informados

##### Resumo

REQUISIÇÃO

##### Parâmetros obrigatórios (caso operação possua departamentos, caso contrário não precisa ser informado)

• departmentId: Id do departamento, lista todas a monitoria de tickets associados a esse departamento.

##### Parâmetros opcionais

• groupId: Identificador do grupo. Se houver mais de um, deve ser separado por vírgula.
• typeId: Identificador do tipo. Se houver mais de um, deve ser separado por vírgula.
• stateId: Identificador do estado. Se houver mais de um, deve ser separado por vírgula.
• startDate: Data/hora inicial para busca, no formato epoch.
• endDate: Data/hora final para busca, no formato epoch.

##### Formato

• O departmentId informado deve ser um GUID válido.
• O(s) groupId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) typeId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) stateId informado(s) deve(m) ser GUID(s) válido(s).
• O período informado por startDate e endDate deve ser válido.
• O período informado deve ter no máximo 31 dias.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	[
	    {
	        "stateId": "...",
	        "stateName": "...",
	        "value": 1
	    },
    	   ...
]

• stateId: GUID que representa o identificador do estado.
• stateName: Nome do Estado.
• value: Quantidade de tickets.

Voltar para todos os sub-recursos

# Monitoria de tickets por tipos

Consulta de tickets de forma sumarizada, por tipo, levando em consideração os parâmetros informados

##### Resumo

REQUISIÇÃO

##### Parâmetros obrigatórios (caso operação possua departamentos, caso contrário não precisa ser informado)

• departmentId: Id do departamento, lista todas a monitoria de tickets por tipos associados a esse departamento.

##### Parâmetros opcionais

• groupId: Identificador do grupo. Se houver mais de um, deve ser separado por vírgula.
• typeId: Identificador do tipo. Se houver mais de um, deve ser separado por vírgula.
• stateId: Identificador do estado. Se houver mais de um, deve ser separado por vírgula.
• startDate: Data/hora inicial para busca, no formato epoch.
• endDate: Data/hora final para busca, no formato epoch.

##### Formato

• O departmentId informado deve ser um GUID válido.
• O(s) groupId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) typeId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) stateId informado(s) deve(m) ser GUID(s) válido(s).
• O período informado por startDate e endDate deve ser válido.
• O período informado deve ter no máximo 31 dias.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	[
	    {
	        "typeId": "...",
	        "typeName": "...",
	        "value": 1
	    },
    	   ...
]

• typeId: GUID que representa o identificador do tipo.
• typeName: Nome do Tipo.
• value: Quantidade de tickets.

Voltar para todos os sub-recursos

# Monitoria de tickets por volumetria

Consulta de tickets de forma sumarizada, abertos e fechados no dia, levando em consideração os parâmetros informados

##### Resumo

REQUISIÇÃO

##### Parâmetros obrigatórios (caso operação possua departamentos, caso contrário não precisa ser informado)

• departmentId: Id do departamento, lista todas a monitoria de tickets associados a esse departamento.

##### Parâmetros obrigatórios (geral)

• startDate: Data/hora inicial para busca, no formato epoch.
• endDate: Data/hora final para busca, no formato epoch.

##### Parâmetros opcionais

• groupId: Identificador do grupo. Se houver mais de um, deve ser separado por vírgula.
• typeId: Identificador do tipo. Se houver mais de um, deve ser separado por vírgula.
• stateId: Identificador do estado. Se houver mais de um, deve ser separado por vírgula.

##### Formato

• O departmentId informado deve ser um GUID válido.
• O(s) groupId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) typeId informado(s) deve(m) ser GUID(s) válido(s).
• O(s) stateId informado(s) deve(m) ser GUID(s) válido(s).
• O período informado por startDate e endDate deve ser válido.
• O período informado deve ter no máximo 31 dias.

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	[
	    {
            "date": 1,
            "opened": 2,
            "closed": 3
        },
    	   ...
]

• date: Data da informação, no formato epoch.
• opened: Quantidade de tickets abertos na data.
• closed: Quantidade de tickets fechados na data.

Voltar para todos os sub-recursos

# Webhook - Criar assinatura

Cria uma assinatura de webhook

REQUISIÇÃO

##### Corpo

{
	"typeName": "...",
	"subscriptionUrl": "..."
}

• typeName: Tipo da assinatura
• subscriptionUrl: Url da API onde serão enviadas as notificações.

##### Formato

• A subscriptionUrl tem que ser válida.
• o typeName tem que ser create ou update

RESPOSTA

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		"id":"...",
		"typeName":"...",
		"url":"..."
	}

• id: GUID que representa o identificador da assinatura.
• typeName: nome do tipo do log, pode ser create ou update.
• url url de assinatura cadastrada (onde vai ser feita a requisição).

Voltar para todos os Sub-Recursos

# Webhook - Listar as assinaturas

Lista as assinaturas de webhook cadastradas para a operação

RESPOSTA

##### Cabeçalhos em caso de erro

##### Corpo em caso de erro

	
	{
		"Message": "subscription not found"
	}
	

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	
	[
		{
			"id":"...",
			"typeName":"...",
			"url":"..."
		},
		...
	]
	

Voltar para todos os Sub-Recursos

# Webhook - Listar as assinaturas de um tipo específico

Lista as assinaturas de webhook cadastradas para a operação e tipo informado

RESPOSTA

##### Parâmetros obrigatórios

• type: O tipo precisa ser create ou update.

##### Cabeçalhos em caso de erro

##### Corpo em caso de erro

	
	{
		"Message": "subscription not found"
	}
	

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	[
		{
			"id":"...",
			"typeName":"...",
			"url":"..."
		},
		...
	]

Voltar para todos os Sub-Recursos

# Webhook - Listar os detalhes de uma assinatura

Consulta os detalhes de uma assinatura de webhook

RESPOSTA

##### Cabeçalhos em caso de erro

##### Corpo em caso de erro

	
	{
		"Message": "subscription not found"
	}
	

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	
	{
		"id":"...",
		"typeName":"...",
		"url":"..."
	}
	

Voltar para todos os Sub-Recursos

# Webhook - Atualizar uma assinatura existente

Atualiza as informações para uma assinatura de webhook

REQUISIÇÃO

##### Corpo

{
	"subscriptionUrl": "..."
}

##### Formato

• A subscriptionUrl tem que ser válida.

RESPOSTA

##### Cabeçalhos em caso de erro

##### Corpo em caso de erro

	
	{
		"Message": "subscription not found"
	}
	

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	{
		"id":"...",
		"typeName":"...",
		"url":"..."
	}

Voltar para todos os Sub-Recursos

# Webhook - Excluir uma assinatura existente

Exclui uma assinatura de webhook existente

RESPOSTA

##### Cabeçalhos em caso de erro

##### Corpo em caso de erro

	
	{
		"Message": "subscription not found"
	}
	

##### Cabeçalhos em caso de sucesso

Voltar para todos os Sub-Recursos

# Webhook - Retornar os eventos de log de uma determinada assinatura

Obtem os logs das informações enviadas para uma assinatura de webhook

RESPOSTA

##### Cabeçalhos em caso de erro

##### Corpo em caso de erro

	
	{
		"Message": "subscription not found"
	}
	

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	
	[
		{
			"id":"...",
			"typeName":"...",
			"responseId":"...",
			"logDate":"...",
			"typeLog":"...",
			"subscriptionUrl":"...",
			"logDetail":"..."
		},
		...
	]
	

• id: GUID que representa o identificador do log.
• typeName: nome do tipo do log, pode ser create ou update.
• responseId: resposta que foi retornada na requisição.
• logDate Data de criação do log, no formato epoch.
• typeLog tipo do log, pode ser success ou error.
• subscriptionUrl url de assinatura cadastrada.
• logDetail detalhes do log.

Voltar para todos os Sub-Recursos

# Webhook - Retornar um payload específico

Retorna os dados de uma notificação específica de webhook

##### Cabeçalhos em caso de erro

##### Corpo em caso de erro

	
	{
		"Message": "subscription not found"
	}
	

RESPOSTA - Assinatura do tipo create

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	
	{
        "Id":"...",
        "Number": "...",
        "Subject":"...",
        "Description": "...",
        "Type": {
                    "Id":"...",
                    "Name":"..."
                },
        "Group": {
                    "Id":"...",
                    "Name":"..."
                },
        "State": {
                    "Id":"...",
                    "Name":"..."
                },
        "Deadline": 1,
        "Responsible":  {
                            "Id":"...",
                            "Name":"..."
                        },
        "CreationDate": "...",
        "CreationUser": {
                        "Id":"...",
                        "Name":"..."
                      },
        "EndDate": 1		
    }
	

RESPOSTA - Assinatura do tipo update

##### Cabeçalhos em caso de sucesso

##### Corpo em caso de sucesso

	
	{
        "Id":"...",
        "Number": "...",
        "Subject":"...",
        "Description": "...",
        "Type": {
                    "Id":"...",
                    "Name":"..."
                },
        "Group": {
                    "Id":"...",
                    "Name":"..."
                },
        "State": {
                    "Id":"...",
                    "Name":"..."
                },
        "Deadline": 1,
        "Responsible":  {
                            "Id":"...",
                            "Name":"..."
                        },
        "CreationDate": "...",
        "EndDate": 1,
		"UpdateDate": 1,
		"UserUpdate": {
				"Id":"...",
				"Name":"..."
			},
		"UpdateDetails":  [
					{
						"Information":"...",
						"Value":"...",
						"InformationType":"...",
						"isPublic":false
					},
					...
				]		
    }
	

• Id: GUID que representa o identificador do ticket.
• Number: Número do ticket (gerado automaticamente para facilitar localização).
• Subject: Assunto.
• Description: Descrição.
• Type: Tipo.
• Group: Grupo.
• State: Estado.
• Deadline: Prazo, no formato epoch.
• Responsible: (pode ser nulo) Responsável.
• CreationDate: Data de criação, no formato epoch.
• EndDate: (pode ser nulo) Data de encerramento, no formato epoch.
• UpdateDate: (pode ser nulo) Data de atualização, no formato epoch.
• UserUpdate: (pode ser nulo) Detalhes da atualização do usuário.
• UpdateDetails: (pode ser nulo) Detalhes da atualização do ticket.
• InformationType: poderá ter um dos seguintes valores: GenericInfo, Attachment ou Comment
• isPublic: indica, caso comentário ou anexo, se é publico ou privado

Voltar para todos os Sub-Recursos

Artigos relacionados:

Gestão de usuários de API