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 para que esta referencia esté completa en un solo lugar; docs.tesser.xyz 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.
Paso 7 · Consultar el saldo en USDC [T]
Operación: GET /v1/accounts/{id}: Consultar una cuenta por 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.
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. |
Paso 8 · Retirar USDC [T]
Operación: POST /v1/treasury/withdrawals: Crear retiro
· 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.
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. |
Paso 9 · Recibir los webhooks de retiro de Tesser [N]
Operación: POST /v1/webhooks/tesser: Recibir webhook de Tesser (Nexa implementa esto)
· 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: 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.
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.
Volver a: Ciclo de vida · Guía de webhooks