Token de Cadastro/Autenticação
URL de homologação: https://hubagnostico-homologacao.linx.com.br/v1
URL de produção:
Parâmetros do header:
| Parâmetro | Tipo | Valor |
| Linx-Cnpj | String | CNPJ do cliente |
| Linx-TokenProduto | String | Token do produto (Microvix, Seta) |
| Linx-TokenParceiro | String | Token do parceiro (Dito, Open Cashback) |
| Linx-IdParceiro | String | ID do parceiro (Obtido no endpoint de parceiros) |
Segue abaixo a lista de endpoints da API:
Para todas as rotas da API, ao retornar um erro de regra de negócio (HTTP 400 - Bad Request), a resposta deve seguir a estrutura abaixo:
{
"IdentificadorTransacao": "string",
"Codigo": 0,
"Mensagem": "string"
}
| Parâmetro | Tipo | Valor |
| IdentificadorTransacao | String | GUID único para rastreamento da transação. Exemplo: 3F2504E0-4F89-41D3-9A0C-0305E82C3301 |
| Código | String | |
| Mensagem | String |
Objetivo
A controller VendasMock foi criada para simular os endpoints de comunicação externa, permitindo que o time de QA realize testes sem dependência de integrações reais com sistemas de parceiros. Ela reproduz os mesmos métodos da comunicação real, porém retorna dados mockados.
Endpoints
Cada endpoint da VendasMock representa uma operação de venda (ex: AtualizarCliente, ConsultarSaldoCliente, etc), e retorna dados mockados com estrutura semelhante à da comunicação externa.
- Request (opcional): Representa os dados enviados na chamada simulada ao sistema externo.
- Response (opcional): Simula o retorno da comunicação externa.
- Header (opcional): Simula os headers utilizados na comunicação, como:
- Cnpj
- TokenProduto
- TokenParceiro
- IdParceiro
Exemplo de estrutura de response para o endpoint AtualizarCliente:
{
"Request": "string",
"Response": "string",
"Header": "string",
"SaldoAtual": 0,
"SaldoDisponivel": 0,
"UtilizaPin": true,
"TipoPin": 0,
"ClienteCadastrado": true
}
Para realizar um mock válido, basta preencher os campos:
{
"SaldoAtual": 0,
"SaldoDisponivel": 0,
"UtilizaPin": true,
"TipoPin": 0,
"ClienteCadastrado": true
}
Estrutura de Armazenamento
Os dados mockados são armazenados em duas tabelas:
arquivo_blob
Armazena o contexto geral da simulação (como se fosse uma "venda"). Campos:
- id_arquivo_blob
- identificador_operacao
arquivo_blob_item
Armazena os "passos" ou etapas da venda (cada chamada de endpoint mock). Campos principais:
- id_arquivo_blob_item_tipo: define o tipo de operação mockada (ex: Mock AtualizaCliente)
- url: link do JSON
- descricao: nome (ex: "Atualizar Cliente.json")
Importante:
O sistema sempre considera o primeiro registro da tabela arquivo_blob para agrupar os mocks da simulação.
Se já existir um mock (registro em arquivo_blob_item) para aquele endpoint, será feito um update.
Se não existir, será feito um insert.
Forçar Tipo de Retorno (tipoRetornoMock)
Importante: O valor informado no parâmetro tipoRetornoMock nesta controller (VendasMock) será refletido posteriormente na controller real de Venda. Aqui, ele apenas registra e armazena essa informação para posterior uso, não executando diretamente o fluxo final.
Nos endpoints da controller VendasMock, é possível forçar um tipo específico de retorno usando o parâmetro tipoRetornoMock na query string:
| Valor | Significado |
|---|---|
| 0 | Sucesso (default) |
| 1 | Erro de Exceção |
| 2 | Erro de Validação |
Obs.: O tipo 0 (sucesso) só será retornado se todo o fluxo estiver completo. Os demais tipos simulam falhas específicas.
Tipos de Mock Suportados
Utilizamos apenas os tipos de arquivo_blob_item_tipo relacionados a mocks.
Exemplos:
| ID | Descrição |
|---|---|
| 11 | Mock AtualizaCliente |
| 12 | Mock ConsultaSaldoCliente |
| 13 | Mock SolicitaPin |
| 14 | Mock ValidaPin |
| 15 | Mock ConsultarCampanha |
| 16 | Mock ValidarBonus |
| 17 | Mock GerarBonus |
| 18 | Mock EstornarBonus |
Considerações Finais
O processo de simulação permite rastrear todos os passos da comunicação, com histórico armazenado no banco.
Os arquivos são salvos em blob storage, e a URL pode ser consultada na coluna url da tabela arquivo_blob_item.