Skip to main content
The Python SDK is suitable for backend services, data tasks, automation agents, and batch processing scripts. acedatacloud is responsible for API calls, while acedatacloud-x402 handles the PAYMENT-SIGNATURE request header. Source code and package addresses:

Install Dependencies

If you want to use upto, you also need to call the Permit2 approve CLI once, which depends on web3:
Output of clean Python venv installation and import check:
Result explanation:
  • Both acedatacloud and acedatacloud-x402 can be installed and imported from PyPI.
  • pip install 'acedatacloud-x402[cli]' will include the approve-permit2 CLI for pre-authorization before upto.

Base or SKALE Example

The following example does not require an API Token. The wallet private key is only used for local signing and will not be sent to Ace Data Cloud.
The current return of the Python SDK is a dict, so the example uses res["choices"][0]["message"]["content"]. Do not directly assume it has a .choices attribute. The program run result of SKALE paid call:
Result explanation:
  • The program completed the 402 parsing, PAYMENT-SIGNATURE signing, and original request retry.
  • content ADC_PY_SDK_X402_OK is a fixed string returned by the model, indicating that the request has entered the target API through the X402 payment link.
  • id chatcmpl-DlcWajqAHOop3iebmO19XRfT5bTPz is the response ID for this chat completion.
When using SKALE, simply change the network name:

Solana Example

Solana uses a base58 encoded secret key:
The Solana path will construct and submit an SPL USDC TransferChecked transaction, then place the transaction signature into the PAYMENT-SIGNATURE envelope. The Solana paid retry has returned HTTP 200 and ADC_SOLANA_E2E_OK on the production API. This public RPC query encountered rate limiting and did not stabilize the confirmation of the on-chain signature; please use your own Solana RPC to query this transaction when reconciliation is needed.

Async Client

The same payment handler can be used for AsyncAceDataCloud:

Using upto for Post-Measurement

The actual cost of APIs such as chat completions and model calls may only be known after the response ends. At this point, the API may return both exact and upto. If you want to prioritize using upto:
The program run result for Base upto:
On-chain confirmation:
Result explanation:
  • content ADC_BASE_UPTO_OK indicates that the request has truly entered the model API.
  • settled value 3 atomic USDC indicates that upto is settled based on actual usage, rather than deducting the full limit.
  • settlement tx can be opened on BaseScan; save the tx hash, payer, completion id, and request summary for reconciliation.
upto uses Permit2 to authorize a limit, and the actual settlement amount cannot exceed this limit. Before the first use, a one-time approve(Permit2, amount) must be done for USDC on the target chain. CLI method:
Program method:
This helper is idempotent. If the allowance is already sufficient, it will return {"skipped": true} and will not repeat the on-chain transaction.

Low-Level Signing

If you do not use the SDK, you can directly call the low-level signing functions:
Low-level functions are suitable for testing, proxy layers, gateway integration, or unofficial SDKs. Regular business code should prioritize using create_x402_payment_handler.