A infraestrutura por trás do crédito

A UY3 é uma SCD autorizada pelo Banco Central. Esta é a documentação das APIs que operam a esteira de crédito — da originação à cobrança, em um único ambiente.

Cada página parte do contexto de negócio — o que o produto faz, quando usá-lo e onde ele entra na esteira — antes de descer ao detalhe técnico de request, response e regras de validação. É o que permite um handoff confiável para o time de implantação: quem integra encontra aqui a trilha completa de cada produto, campo a campo, sem depender de conhecimento tácito.

A esteira

Todo produto de crédito da UY3 percorre a mesma esteira, nesta ordem:

Originação → Simulação → KYC → Compliance → Formalização → Liquidação → Cessão → Gestão → Cobrança

Nem todo produto usa todas as etapas, e nenhum produto as reordena. Quando a documentação de um módulo diverge dessa sequência, a divergência é explicada na página — a ordem é uma informação de negócio, não uma escolha editorial.

Prazos de liquidação são sempre D+0 / D+1, conforme o produto.

Como este portal é organizado

A navegação segue o catálogo oficial de produtos da UY3, não a arquitetura interna dos serviços. Você não precisa saber em qual API o endpoint mora: precisa saber qual produto quer integrar.

Escopo desta versão: dois produtos

Esta versão da documentação cobre dois produtos, e só eles:

Os dois são de CaaS Massificados, uma das três famílias do portfólio da UY3 — as outras são CaaS Estruturados e BaaS. Os demais produtos do catálogo (Empréstimo pessoal, Consignado público, Buy Now Pay Later, Home Equity, Crédito estudantil, Cartão consig. saque, Veículos, Nota Comercial, CCB – Operações estruturadas, Conta escrow, Conta pagamento, Transferências e Cobrança bancária, além de INSS, Cartão consig. rotativo e Parcelamento de contas, em construção) entram na navegação quando forem migrados para este mesmo padrão.

A decisão é deliberada: em vez de manter treze produtos em formatos diferentes, dois foram levados ao padrão completo para servir de molde. Se você precisa de um produto que não está aqui, fale com a equipe de tecnologia da UY3.

A estrutura de um módulo

Cada módulo tem cinco etapas, na ordem em que se integra: visão geral, pré-requisitos e cadastros, operação, consultas e acompanhamento (com os eventos do ciclo de vida) e erros e troubleshooting. Os dois módulos têm a mesma hierarquia de seções — é o que permite trocar de produto sem reaprender a navegar, e é o molde que os próximos produtos vão seguir.

Navegando só pelos links internos de cada página é possível percorrer o fluxo inteiro, do primeiro cadastro à consulta final, sem tocar no menu.

A ordem das etapas é uma informação, não uma decoração

Dentro de um módulo, a ordem dos cadastros é a ordem em que o negócio permite executá-los — e ela nem sempre é a intuitiva. No Consignado privado, por exemplo, a autorização de margem vem antes do cadastro do tomador, porque ela se identifica por CPF e telefone e não exige cadastro nenhum. Isso existe para você não coletar dado pessoal completo de quem ainda não se sabe se tem margem.

Cada página explica por que está naquela posição. Quando dois módulos divergem na sequência, a divergência é explicada nos dois.

Cadastros ficam dentro do módulo dono

Não existe página de cadastro solta na navegação. O cadastro de uma Pessoa Física, por exemplo, é o mesmo recurso em vários produtos — mas o preenchimento é diferente em cada um: no Consignado privado os campos de vínculo empregatício são o que sustenta a averbação; no FGTS eles não se aplicam. Por isso cada módulo traz o seu cadastro, com instrução campo a campo de como preencher naquele contexto.

Modelos de cálculo, em Referência técnica

O modelo de cálculo (amortizationType) não é o produto, mas condiciona o que a operação aceita: a API exige que o valor enviado seja exatamente o do produto contratado, e é ele que determina quais campos existem no objeto de cálculo. O catálogo completo, gerado do contrato, está em /operacoes.

Consignado privado, INSS, Consignado público, Cartão consig. saque e Veículos não têm modelo de cálculo próprio: todos rodam em Price, e o que os distingue é a garantia averbada. Por isso a garantia é documentada dentro de cada tipo de operação, com o payload campo a campo e o motivo pelo qual ela é exigida — não em uma página separada.

O que você encontra em cada módulo

1. Visão geral — o que é o produto, para quem serve e o fluxo ponta a ponta, com cada passo linkando para a página que o executa. É aqui também que ficam os botões de download dos artefatos de integração.
2. Pré-requisitos e cadastros — o que a UY3 provisiona, a ordem dos cadastros e por que ela é essa. Cada cadastro tem sua página, com a tabela Campo | Tipo | Obrigatório | Como preencher | Exemplo.
3. Operação — os endpoints do fluxo principal, com descrição de negócio, parâmetros, exemplo de request e response e códigos de retorno.
4. Consultas e acompanhamento — status, listagens e comprovante. Com uma subpágina Eventos e notificações, que documenta o ciclo de vida completo: cada estado, quando acontece e se exige ação sua.
5. Erros e troubleshooting — os erros que aparecem de fato, agrupados por etapa, com causa e ação corretiva.

Toda página traz, no fim, Antes desta etapa, Próxima etapa e Downloads.

Artefatos para levar embora

Na visão geral de cada módulo, três atalhos:

• Contexto para LLM do módulo — todas as páginas daquele produto em um arquivo de texto, na ordem do fluxo. É o que faz um assistente acertar a sequência em vez de adivinhar.
• Collection do Postman do módulo — requisições prontas, em pastas na ordem das etapas.
• Integração via MCP — conecte seu assistente de IA direto nesta documentação: ele consulta os guias e a Referência enquanto você escreve o código. Ver MCP para integração.

Tudo reunido em Downloads.

Convenções que valem para todos os campos

Formato de data, unidade de valor monetário e leitura de taxa seguem um padrão único, em Convenções de dados. Nenhum campo é documentado de forma diferente do que está lá. Vale a leitura antes do primeiro POST: errar unidade não devolve 400, devolve operação com o valor errado.

Complementando os módulos

• Referência de API — todos os endpoints do contrato de Crédito, cada um com request e response campo a campo e um cURL pronto para copiar. Os erros seguem o formato application/problem+json (RFC 7807).
• Copiar para LLM — o contrato em formato pronto para colar em um assistente de IA.

Na prática — tabela campo-a-campo

Exemplo do formato usado em todas as referências de payload (dados fictícios):

Os campos abaixo são os da criação de operação de crédito (POST /v1/CreditNote), lidos do contrato:

Na prática — enum explicado valor-a-valor

Os enums são explicados valor a valor, com o significado de cada um. Exemplo com amortization.calculateByValueType, que define como o valor informado é interpretado:

A lista completa de valores de amortizationType não é escrita à mão em nenhum guia: ela é gerada do contrato no Catálogo de tipos de operação, com os campos e as regras de cada finalidade. Guia e contrato não podem divergir se só um dos dois é a fonte.

Na prática — erro no formato problem+json

Todo erro previsto é retornado no formato application/problem+json (RFC 7807), com dados fictícios:

{
  "type": "https://docs.uy3.com.br/errors/validation",
  "title": "Requisição inválida",
  "status": 400,
  "detail": "O campo 'productId' é obrigatório.",
  "instance": "/v1/CreditNote",
  "traceId": "00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01"
}

Fonte da verdade

A Referência de API e o Catálogo de tipos de operação são gerados em runtime do contrato da API — endpoints, campos, tipos, obrigatoriedade e enums saem do que o serviço expõe, não de texto mantido à parte. Sobre essa base fica a camada curada de negócio, escrita nas páginas de cada módulo.

Dado pessoal deve ser mascarado em qualquer output, log ou ticket — os exemplos deste portal usam sempre dados fictícios. A classificação de quais campos são dado pessoal e o tratamento aplicável são decisão do Compliance/Jurídico UY3.

Por onde começar

Se é sua primeira integração, siga Primeiros passos, leia Convenções de dados e escolha um dos dois módulos na navegação à esquerda. Se já tem credenciais, vá direto para a visão geral do produto e baixe o contexto para LLM e a collection do Postman.