Skip to main content
Python SDK підходить для бекенд-сервісів, даних завдань, автоматизованих агентів та пакетних скриптів. acedatacloud відповідає за виклики API, acedatacloud-x402 відповідає за підписання заголовка запиту PAYMENT-SIGNATURE. Джерела та адреси пакетів:

Встановлення залежностей

Якщо потрібно використовувати upto, також потрібно одноразово викликати Permit2 approve CLI, цей CLI залежить від web3:
Вихід установки та перевірки імпорту чистого Python venv:
Роз’яснення результатів:
  • acedatacloud та acedatacloud-x402 можна встановити та імпортувати з PyPI.
  • pip install 'acedatacloud-x402[cli]' включає approve-permit2 CLI для попереднього авторизації upto.

Base або SKALE приклад

Наступний приклад не потребує API Token. Приватний ключ гаманця підписується лише локально, не буде надісланий до Ace Data Cloud.
Python SDK наразі повертає dict, тому приклад використовує res["choices"][0]["message"]["content"]. Не припускайте, що він обов’язково має атрибут .choices. Результат виконання програми SKALE paid call:
Роз’яснення результатів:
  • Програма завершила 402 парсинг, підписання PAYMENT-SIGNATURE та повторний запит.
  • content ADC_PY_SDK_X402_OK є фіксованим рядком, який дійсно повертає модель, що вказує на те, що запит пройшов через платіжний ланцюг X402 до цільового API.
  • id chatcmpl-DlcWajqAHOop3iebmO19XRfT5bTPz є ID відповіді на цей chat completion.
При використанні SKALE потрібно лише змінити назву мережі:

Solana приклад

Solana використовує секретний ключ, закодований у base58:
Шлях Solana буде побудований та надісланий SPL USDC TransferChecked транзакцію, а потім підписана транзакція буде поміщена в PAYMENT-SIGNATURE envelope. Solana paid retry на виробничому API вже повернув HTTP 200 та ADC_SOLANA_E2E_OK. Цей публічний RPC запит зіткнувся з обмеженнями, не було стабільного підтвердження підпису в ланцюзі; для звірки використовуйте свій власний Solana RPC для перевірки цієї транзакції.

Async клієнт

Той самий payment handler може бути використаний для AsyncAceDataCloud:

Використання upto для пост-обліку

Справжня вартість API, така як чат-комплітації, виклики моделей тощо, може бути відома лише після завершення відповіді. У цей момент API може одночасно повертати exact та upto. Якщо потрібно віддати перевагу upto:
Результат виконання програми Base upto:
Підтвердження в ланцюзі:
Роз’яснення результатів:
  • content ADC_BASE_UPTO_OK вказує на те, що запит дійсно потрапив до API моделі.
  • settled value 3 atomic USDC вказує на те, що upto розраховується за фактичним використанням, а не знімається повна межа.
  • settlement tx можна відкрити на BaseScan, для звірки зберігайте tx hash, payer, completion id та підсумок запиту.
upto використовує Permit2 для авторизації межі, фактична сума розрахунку не може перевищувати цю межу. Перед першим використанням потрібно зробити один раз approve(Permit2, amount) для USDC на цільовій ланцюзі. CLI спосіб:
Програмний спосіб:
Цей хелпер є ідемпотентним. Якщо allowance вже достатньо, він поверне {"skipped": true}, не повторюючи транзакцію в ланцюзі.

Низькорівневе підписання

Якщо ви не використовуєте SDK, ви також можете безпосередньо викликати низькорівневі функції підпису:
Низькорівневі функції підходять для тестування, проксі-слою, інтеграції шлюзу або неофіційного SDK. Звичайний бізнес-код повинен переважно використовувати create_x402_payment_handler.