4.4. Dados Bancários¶

Especificação — em construção

Os serviços descritos nesta área ainda não estão disponíveis.

🔗 Endpoint¶

Método	URL
	`/credito/propostas/{idProposta}/dados-bancarios`

🧾 Descrição¶

Informa a conta bancária do tomador — a conta na qual o valor da operação será creditado.

Etapa condicional

Esta etapa se aplica quando o desembolso vai para o tomador, ou seja quando destinatarioDesembolso é 1 (Emitente) ou null. Em esteiras de CDC configuradas com desembolso ao parceiro (= 2), esta chamada é recusada — use 6.3. Desembolso ao Parceiro. As duas etapas são mutuamente exclusivas: em nenhuma configuração as duas se aplicam.

Em EP o desembolso vai sempre para o tomador, então esta etapa é sempre obrigatória.

🔹 Path Parameter¶

Parâmetro	Tipo	Descrição
idProposta	integer	Identificador da proposta

📤 Requisição¶

{
  "idBanco": 1,
  "agencia": "12345",
  "conta": "9876543",
  "tipoConta": 2
}

🧾 Detalhamento dos Campos¶

Campo	Tipo	Obrigatório	Descrição
idBanco	integer	Sim	Código do banco. Ver `GET /enumeracoes/bancos`
agencia	string	Sim	Agência com o dígito verificador, quando houver
conta	string	Sim	Conta com o dígito verificador
tipoConta	integer	Sim	`1` Poupança, `2` Corrente

🔢 Dígito verificador¶

Não existe campo separado para o dígito. Envie agência e conta como um único valor e a plataforma separa o dígito ao comunicar com a bancarizadora:

Campo	Regra
`agencia`	Quando tem 5 dígitos, o último é tratado como dígito verificador
`conta`	O último caractere é sempre tratado como dígito verificador

Exemplos:

Valor enviado	Interpretação
`agencia: "12345"`	agência `1234`, dígito `5`
`agencia: "1234"`	agência `1234`, sem dígito
`conta: "9876543"`	conta `987654`, dígito `3`
`conta: "00012345X"`	conta `00012345`, dígito `X`

Envie somente dígitos e letras, sem pontos, hífens ou espaços.

🧪 Exemplo de cURL¶

curl -X PUT "https://api.vehub.com.br/credito/propostas/1001/dados-bancarios" \
  -H "Authorization: Bearer {seu_token}" \
  -H "GrupoEconomico: {seu_grupo_economico}" \
  -H "Content-Type: application/json" \
  -d '{
    "idBanco": 1,
    "agencia": "12345",
    "conta": "9876543",
    "tipoConta": 2
  }'

📥 Responses¶

✅ 200 OK¶

{
  "sucesso": true,
  "mensagem": "Dados bancários salvos com sucesso.",
  "dados": null
}

❌ 409 Conflict¶

Quando a esteira desembolsa ao parceiro:

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.10",
  "status": 409,
  "errors": [
    { "campo": null, "mensagem": "A etapa de dados bancários não está disponível quando o desembolso é destinado ao parceiro." }
  ]
}

⚠️ A conta pertence ao tomador, não à proposta¶

Este é o comportamento que mais surpreende quem integra: a conta bancária é gravada no cadastro do tomador, e não na proposta.

Consequências práticas:

Duas propostas do mesmo CPF compartilham a mesma conta.
A última gravação vence: informar uma conta nova em uma proposta altera a conta que a outra proposta também usaria.
Se o cliente tem mais de uma conta e você precisa desembolsar em contas diferentes por operação, isso não é suportado hoje.

Na prática: confirme a conta com o cliente a cada operação e trate a informação como "a conta atual do tomador", não como "a conta desta proposta".

🧭 Próximo passo¶

Com a conta informada, siga para 6.2. Simulação da Proposta — ou consulte proximaEtapa em 6.10 e deixe a API dizer o que falta.