---
title: 9.3. Roteiro — Jornada simplificada
url: https://docs.vehub.com.br/Emiss%C3%A3o%20de%20Ativos/API/Cr%C3%A9dito/9.%20Roteiros/9.3.%20Roteiro%20-%20Jornada%20simplificada/
---
# 9.3. Roteiro — Jornada simplificada

!!! warning "Especificação — em construção"
   Os serviços descritos nesta área ainda não estão disponíveis.

Roteiro para esteiras com `dadosSimplificadosAnaliseCredito = true`. Nessa configuração, a proposta
vai ao **motor de crédito logo depois da simulação**, com o mínimo de dados — e a ficha completa só é
exigida se a análise aprovar.

**Por que existe:** evita que o vendedor gaste tempo preenchendo a ficha inteira de uma proposta que o
motor recusaria de imediato. Mais propostas originadas por dia, menos retrabalho.

---

## A diferença

```mermaid
flowchart LR
    subgraph Completa
        A1[Tomador completo] --> A2[Bancários] --> A3[Simulação]
        A3 --> A4[Avalistas] --> A5[Garantias] --> A6[Documentos]
        A6 --> A7[Análise] --> A8[Envio]
    end
    subgraph Simplificada
        B1[Tomador básico] --> B2[Simulação] --> B3[Análise]
        B3 --> B4[Complementares] --> B5[Bancários] --> B6[Avalistas]
        B6 --> B7[Garantias] --> B8[Documentos] --> B9[Envio]
    end
```

Na simplificada, a **análise acontece na terceira etapa**, não na sétima.

---

## Como saber se está ativa

```bash
curl "https://api.vehub.com.br/credito/esteiras/12/parametros" \
  -H "Authorization: Bearer $TOKEN" -H "GrupoEconomico: $GE"
```

```json
{
  "operacao": {
    "enviarParaAnaliseCredito": true,
    "dadosSimplificadosAnaliseCredito": true,
    "sugerirNovaAnaliseComDados": true
  }
}
```

Três condições:

| Parâmetro | Efeito |
|---|---|
| `enviarParaAnaliseCredito: true` | **Pré-requisito.** Sem análise, a simplificada não faz sentido e não produz efeito |
| `dadosSimplificadosAnaliseCredito: true` | Ativa a reordenação |
| `sugerirNovaAnaliseComDados: true` | Permite **uma** segunda análise após recusa, com a ficha enriquecida |

> A configuração é da esteira e **não pode ser sobrescrita por proposta**. Vale sempre o que está
> configurado.

!!! tip "Você não precisa ramificar o seu código"
    Se a sua integração segue `proximaEtapa` da proposta, ela funciona nas duas jornadas sem nenhuma
    condicional. Este roteiro existe para explicar **por que** a ordem muda, não para pedir um
    segundo caminho de código.

---

## 1 a 4. Autenticar, esteira, parâmetros e simular avulsa

Idênticos ao [roteiro de EP](9.1.%20Roteiro%20-%20EP%20ponta%20a%20ponta.md).

---

## 5. Criar proposta com o tomador básico

Nesta jornada você pode criar a proposta com o **mínimo**: identificação, contato e endereço.

```json
{
  "tomador": {
    "tipo": 1,
    "nome": "João da Silva",
    "documento": "12345678900",
    "data": "1988-04-12",
    "telefone": "47999998888",
    "email": "joao@exemplo.com",
    "endereco": {
      "cep": "89010000",
      "endereco": "Rua das Flores",
      "numero": "120",
      "bairro": "Centro",
      "cidade": "Blumenau",
      "uf": "SC"
    }
  }
}
```

```bash
curl -X POST "https://api.vehub.com.br/credito/esteiras/12/propostas" \
  -H "Authorization: Bearer $TOKEN" -H "GrupoEconomico: $GE" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d @tomador-basico.json
```

Campos como nome da mãe, estado civil, escolaridade, CNH e vínculo de renda **ficam para depois**.

---

## 6. Simular a proposta

```bash
curl -X POST "https://api.vehub.com.br/credito/propostas/1001/simulacao" \
  -H "Authorization: Bearer $TOKEN" -H "GrupoEconomico: $GE" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "tipoSimulacao": 1, "valor": 18000.00, "taxa": 1.99, "quantidadeParcelas": 24, "dataPrimeiroVencimento": "2026-10-10" }'
```

Aguarde `credito.simulacao.concluida`.

---

## 7. Análise de crédito — **já aqui**

```bash
curl -X POST "https://api.vehub.com.br/credito/propostas/1001/analise-credito" \
  -H "Authorization: Bearer $TOKEN" -H "GrupoEconomico: $GE" \
  -H "Idempotency-Key: $(uuidgen)"
```

Sem dados bancários, sem avalistas, sem garantias, sem documentos. A validação de submissão é
**afrouxada** nesta configuração: bastam os dados básicos e a simulação.

Aguarde `credito.analise.concluida`.

---

## 8. O caminho se abre em três

```mermaid
flowchart TD
    A[credito.analise.concluida] --> B{status}
    B -- Aprovado / Aprovado com alteração --> C[Completar a ficha]
    B -- Recusado + sugerirNovaAnaliseComDados --> D[Segunda chance]
    B -- Recusado sem segunda chance --> E[Fim: informar o cliente]
    C --> F[Envio da proposta]
    D --> G[Completar a ficha] --> H[Nova análise]
    H --> I{status}
    I -- Aprovado --> F
    I -- Recusado --> E
```

### 8a. Aprovada — complete a ficha

```bash
curl -X PUT "https://api.vehub.com.br/credito/propostas/1001/tomador" \
  -H "Authorization: Bearer $TOKEN" -H "GrupoEconomico: $GE" \
  -H "Content-Type: application/json" \
  -d @tomador-completo.json
```

!!! danger "Envie o tomador completo, não só os campos novos"
    O `PUT` é **substituição total**: os arrays `pessoas`, `cnae` e `faturamento` são reconciliados e
    os itens ausentes são removidos. Monte o payload a partir do `GET` da proposta, acrescente os
    campos complementares e reenvie o conjunto inteiro. Ver
    [4.3](../4.%20Tomador/4.3.%20Pessoa%20Jurídica%20e%20Representantes.md).

Em seguida, siga `proximaEtapa` pelas etapas restantes: bancários, avalistas, garantias, documentos.
Note que a lista de documentos pode ter **mudado** depois do complemento da ficha — consulte-a
novamente.

### 8b. Recusada com segunda chance

Se `status` é `Recusado`, `sugerirNovaAnaliseComDados` é `true` e `novaAnaliseSolicitada` é `false`,
você pode enriquecer a ficha e submeter **uma** nova análise:

1. `PUT /credito/propostas/1001/tomador` com a ficha completa
2. `PUT /credito/propostas/1001/dados-bancarios`
3. Avalistas e garantias, se aplicável
4. `POST /credito/propostas/1001/documentos/{id}` para cada documento
5. `POST /credito/propostas/1001/analise-credito` — nova submissão

Depois dessa segunda submissão, `novaAnaliseSolicitada` passa a `true` e novas tentativas são
recusadas.

### 8c. Recusada sem segunda chance

A jornada termina. Informe o cliente e, se quiser, cancele a proposta — ela ainda está em
*Em digitação* se nada mais foi feito.

---

## 9 a 11. Envio, formalização e carteira

Idênticos ao [roteiro de EP](9.1.%20Roteiro%20-%20EP%20ponta%20a%20ponta.md), passos 11 a 13.

Antes do envio, confirme `pendencias: []` — a análise aprovada não basta: a ficha e os documentos
continuam obrigatórios.

---

## ⚠️ Pontos de atenção

### A análise aprovada não dispensa a ficha

Aprovação antecipada é uma **triagem**, não uma liberação. O envio da proposta continua exigindo ficha
completa, dados bancários e documentos. A economia está em não coletar nada disso de propostas que
seriam recusadas.

### A lista de documentos pode mudar

Ao completar a ficha — especialmente se você adicionar sócios ou representantes legais numa PJ — a
lista de documentos exigidos é **recalculada**. Consulte
`GET /credito/propostas/{id}/documentos` depois de cada `PUT /tomador`.

### Uma segunda análise, não várias

`sugerirNovaAnaliseComDados` libera **exatamente uma** nova submissão. Não há como pedir uma terceira.

### O reenvio é controlado

Fora dessa exceção, a plataforma **não** reenvia proposta ao motor. Uma proposta com resultado já
recebido não admite nova submissão.

---

## ✅ Checklist adicional ao do roteiro de EP

- [ ] `dadosSimplificadosAnaliseCredito` e `enviarParaAnaliseCredito` consultados juntos
- [ ] Proposta criada com o tomador básico, sem exigir a ficha completa do vendedor
- [ ] Análise submetida logo após a simulação
- [ ] `PUT /tomador` enviado com o objeto **completo**, não parcial
- [ ] Lista de documentos reconsultada após completar a ficha
- [ ] `novaAnaliseSolicitada` verificado antes de tentar a segunda análise
- [ ] `pendencias: []` confirmado antes do envio