Aceitando a cotação

Aceitar a cotação é o ponto em que o offramp deixa de ser cotação descartável e vira operação. A chamada é idempotente via header Idempotency-Key.

O que a chamada faz

POST /v1/quotes/:id/accept

Em uma única transação atômica:

1. Marca a cotação como consumed e a vincula à conversão criada.
2. Cria a conversão em awaiting_deposit.
3. Emite o endereço de depósito USDT, exclusivo desta conversão.
4. Reserva o limite de operação contra o cliente final, no valor expected_source_amount.
5. Abre a janela de depósito de 15 minutos, contadas a partir do aceite.
6. Snapshota a configuração de taxas vigente da sua organização na conversão. Renegociações futuras não afetam esta operação.
7. Dispara o webhook conversion.created.

O que volta

A resposta carrega a conversão completa: id, status='awaiting_deposit', quote_id, expected_source_amount, deposit_address, deposit_address_network, deposit_window_expires_at, e os campos de snapshot de taxas. Os campos exatos vão na referência da API quando publicada.

A janela de 15 minutos começa aqui

deposit_window_expires_at = aceite + 15 minutos. Esse é o intervalo em que um depósito no valor exato leva a conversão direto para funded. Depósito após o prazo, com received_amount > 0, leva a conversão para standby com standby_reason='window_expired'.

Erros narrativos

A chamada falha em alguns cenários previsíveis. Códigos exatos vão na referência da API.

• Cotação expirada (expires_at no passado): erro de validação. Crie uma cotação nova.
• Cotação já consumida (você já aceitou esta cotação ou outra chamada tomou a janela): erro de conflito. Cheque o consumed_by_conversion_id retornado em GET /v1/quotes/:id e use a conversão existente.
• Cliente final já tem outra conversão offramp aberta: erro de lock. Veja Lock por usuário e tipo para o tratamento.
• Limite excedido para o cliente final: erro de validação. A reserva não é feita; a conversão não é criada.

Próximo passo

• Recebendo o depósito: o que acontece quando o USDT chega no endereço.