Skip to main content
TypeScript es una de las formas más recomendadas para integrar Ace Data Cloud X402. El SDK oficial se encarga de las llamadas API comunes, la consulta de tareas, el manejo de errores y los reintentos automáticos; @acedatacloud/x402-client se encarga de firmar el encabezado de solicitud PAYMENT-SIGNATURE cuando se encuentra con 402 Payment Required. Direcciones del código fuente y del paquete:

Instalación de dependencias

Si se utiliza Base o SKALE, se necesita la capacidad de firma EVM:
Si se utiliza Solana, se necesita el adaptador de billetera de Solana o @solana/web3.js:
Salida de verificación de instalación e importación de un proyecto npm limpio:
Descripción de los resultados:
  • @acedatacloud/sdk y @acedatacloud/x402-client se pueden instalar desde npm y ser importados por Node.js.
  • ethers se utiliza para la firma de datos tipados EVM, @solana/web3.js se utiliza para la construcción de transacciones de Solana.

Ejemplo de Base o SKALE

Se puede usar directamente window.ethereum en el navegador. En Node.js, se puede envolver ethers.Wallet en un proveedor de estilo EIP-1193.
Resultado de la ejecución del programa de este ejemplo:
Descripción de los resultados:
  • El programa primero activa un 402 sin autenticación, luego el handler firma el PAYMENT-SIGNATURE, y finalmente reintenta con el mismo cuerpo de solicitud.
  • content ADC_TS_SDK_X402_OK es una cadena fija devuelta realmente por el modelo, lo que indica que la solicitud reintentada ingresó a la API objetivo.
  • id chatcmpl-DlcVLO4PQWvmjPDQpy9yQw2QdLGAT es el ID de respuesta de esta finalización de chat, que se puede usar para comparar con los registros de uso de la plataforma.
  • Los resultados de liquidación en la cadena se pueden ver en Verificación E2E y solución de problemas.
Cambia network a skale para usar SKALE. La ventaja de SKALE es que el costo de gas de las transacciones en la cadena es bajo; la ventaja de Base es la liquidez de USDC y el soporte de billeteras más maduro, y solo Base ofrece medición posterior upto. Nota: SKALE actualmente solo tiene exact. Si se pasa preferScheme: 'upto' bajo network: 'skale', el handler no encontrará upto y volverá silenciosamente a exact, sin generar un error; esto hará que escenarios como la finalización de chat, que se miden por token, se liquiden a una tarifa fija en lugar de por el uso real. Para medición posterior, utilice Base.

Ejemplo de billetera del navegador

Al usar MetaMask, Coinbase Wallet o WalletConnect en aplicaciones frontend, generalmente se pasa directamente el proveedor EIP-1193:
La billetera del navegador mostrará un cuadro de confirmación de firma. El usuario no firma un mensaje arbitrario, sino la solicitud de pago devuelta por la API: la dirección de recepción, el contrato USDC, el monto, la validez y el nonce están todos incluidos en la firma.

Ejemplo de Solana

Solana utiliza SPL USDC TransferChecked. El adaptador de billetera pasado necesita exponer publicKey y signAndSendTransaction.
La ruta de Solana actualmente solo admite exact, no admite upto. Si la API devuelve múltiples accepts, el handler seleccionará el que tenga network = 'solana'. La ruta de Solana ha verificado que el reintento pagado puede devolver HTTP 200 y ADC_SOLANA_E2E_OK en la misma API pública. Las consultas RPC públicas pueden estar limitadas, por lo que este documento no incluye el hash de la transacción de Solana; si necesita conciliación en la cadena, utilice su propio RPC de Solana o registre la confirmación en la consola.

Elegir exact o upto

El handler de TypeScript actual seleccionará el primer requisito de pago que coincida con la red devuelta por el servidor. La API de Ace Data Cloud generalmente coloca el exact de la misma red antes del upto, por lo que si desea claramente utilizar la medición posterior, debe pasar preferScheme: 'upto'. Ejemplo:
Si el servidor no ha devuelto el requisito upto para esa red, el handler volverá automáticamente al primer requisito disponible de esa red, que generalmente es exact. upto requiere autorización única de Permit2. upto actualmente solo se ofrece en Base, por lo que solo necesita autorizar una vez el USDC de Base:
Base upto ha completado la verificación de API pública: HTTP 402 -> HTTP 200, la transacción de liquidación posterior es 0x4b0b836ce1cd1171cdbc37df1637150b024214ec28e7f6f2d09122f15cbfc036. La salida completa se puede ver en la descripción del plan de facturación.

¿Qué hizo el SDK?

El transporte de @acedatacloud/sdk ejecutará un manejador de pagos al recibir un 402:
El manejador devuelto por @acedatacloud/x402-client hará:
  1. Seleccionará el requisito de pago de la red objetivo de ctx.accepts.
  2. Construirá una firma EVM EIP-712 o una transacción de transferencia de Solana según la red.
  3. Serializará el sobre en Base64.
  4. Devolverá { headers: { 'PAYMENT-SIGNATURE': '<base64>' } }.
  5. El SDK automáticamente reintentará con el cuerpo de la solicitud original.
Esto significa que el código de negocio solo necesita escribirse como una llamada normal al SDK, sin necesidad de manejar manualmente el reintento de 402.