# 5 · Tesorería

La fase 5 corre **en paralelo** al flujo de la cotización, no después de él,
y es la única fase en la que Nexa es quien llama en los tramos de API. Nexa
va acumulando el USDC de los depósitos contra los que acredita GTQ; esta fase
es la forma en que ve ese saldo y lo convierte para sacarlo. La conversión de
USDC a USD que hace BitGo y el desembolso hacia el banco propio de Nexa
quedan fuera de alcance. Las llamadas a la API de Tesser sí están dentro del
alcance.

Estas son **operaciones ya existentes y en producción de la API principal de
Tesser**. Están incorporadas en
[Endpoints de Tesser expuestos a Nexa](/api-tesser) para que esta referencia
esté completa en un solo lugar;
<a href="https://docs.tesser.xyz" target="_blank">docs.tesser.xyz</a> sigue
siendo la fuente normativa, y las copias incorporadas se comparan en CI
contra la definición en producción, de modo que no se pueden desactualizar en
silencio.

<Mermaid
  chart={`sequenceDiagram
    autonumber
    participant T as Tesser (orquestador)
    participant N as Banco Nexa

    Note over T,N: Fase 5 · Tesorería de Nexa (API principal existente de Tesser)
    N->>T: GET /v1/accounts/{id} [T]
    T-->>N: 200 AccountResponseDto (saldo en USDC)
    N->>T: POST /v1/treasury/withdrawals [T]
    T-->>N: 201 WithdrawalResponse
    T->>N: webhook: estado del retiro → receptor de Nexa [N]`}
/>

## Paso 7 · Consultar el saldo en USDC <T />

**Operación:** [`GET /v1/accounts/{id}`: Consultar una cuenta por ID](/api-tesser/accounts#get-an-account-by-id)
· lo aloja **Tesser**, lo llama **Nexa**.

El ID de la cuenta de la billetera USDC de Nexa se comparte durante el
onboarding (MVP de una sola billetera). La respuesta es el
`AccountResponseDto` de la API principal.

<div className="what-can-go-wrong">

**Qué puede salir mal: consultar la cuenta**

Estos son códigos de error de la **API principal** de Tesser, no el
vocabulario de `error_code` que usan los endpoints de cotización expuestos a
Nexa.

| Error | HTTP | Cuándo |
| --- | --- | --- |
| `counterparties-3001` / `counterparties-3002` | 400 | Solicitud inválida. |
| `api-0004` | 401 | Falta el certificado de cliente o la llave de API, o son inválidos. |
| `api-0001` | 404 | No existe ninguna cuenta con este ID, o no es visible para la organización de Nexa. |
| `api-0006` | 500 | Falla inesperada del lado de Tesser. |

</div>

## Paso 8 · Retirar USDC <T />

**Operación:** [`POST /v1/treasury/withdrawals`: Crear retiro](/api-tesser/treasury#create-withdrawal)
· lo aloja **Tesser**, lo llama **Nexa**.

La solicitud es el `CreateWithdrawalRequest` de la API principal
(`organization_reference_id` más una capa `desired`); la respuesta es un
`WithdrawalResponse`. El avance del estado llega por los webhooks salientes
estándar de retiro de Tesser, que es el paso 9.

<div className="what-can-go-wrong">

**Qué puede salir mal: crear el retiro**

| Error | HTTP | Cuándo |
| --- | --- | --- |
| `counterparties-3001` / `counterparties-3002` | 400 | Solicitud inválida. |
| `api-0004` | 401 | Falta el certificado de cliente o la llave de API, o son inválidos. |
| `api-0006` | 500 | Falla inesperada del lado de Tesser. |

</div>

## Paso 9 · Recibir los webhooks de retiro de Tesser <N />

**Operación:** [`POST /v1/webhooks/tesser`: Recibir webhook de Tesser (Nexa implementa esto)](/api-nexa/webhooks#receive-tesser-webhook-nexa-implements-this)
· lo aloja **Nexa**, lo llama **Tesser**.

Este es el único endpoint del documento alojado por Nexa que Nexa construye
en beneficio de Tesser y no propio. Recibe los webhooks salientes estándar de
Tesser, que aquí son las actualizaciones del estado del retiro del paso 8. El
sobre y los tipos de evento son los que Tesser ya tiene; este portal documenta
la suscripción que Nexa necesita y enlaza a la documentación principal en
lugar de volver a especificarlos.

La autenticación de la entrega se cubre en
[Autenticación](/es/authentication): hoy el emisor de webhooks de Tesser
firma con Ed25519 (`X-Tesser-Signature`) y se está ampliando para que
presente un certificado de cliente en las entregas hacia Nexa.

<div className="what-can-go-wrong">

**Qué puede salir mal: entrega de webhooks de Tesser hacia Nexa**

| `error_code` | HTTP | Cuándo |
| --- | --- | --- |
| `VALIDATION_ERROR` | 400 | Sobre mal formado o tipo de evento desconocido. |
| `UNAUTHENTICATED` | 401 | Firma inválida o, una vez que esté listo el mTLS saliente, certificado de cliente ausente o no reconocido. |
| `INTERNAL_ERROR` | 500 | Falla inesperada del lado de Nexa. **Este sí lo reintenta Tesser.** |

Cualquier 2xx con cuerpo vacío es éxito. Cualquier otra cosa se reintenta,
así que el receptor debe ser idempotente respecto al id del evento.

</div>

**Volver a:** [Ciclo de vida](/es/flow-nexa/lifecycle) ·
[Guía de webhooks](/es/webhooks-guide)