cryptoinfraDocs

Merchant API · OpenAPI 1.0.0

cryptoinfra — white-label crypto infrastructure

You bring the users. The platform gives each of them a Static Wallet Address on TRON, watches it, credits confirmed deposits to a double-entry ledger, and executes payouts on their behalf — over one REST API, with no private key ever in your hands.

Quickstart — six calls Introduction API reference For agents
  • TRON
Operations
68
Schemas
56
Webhook events
9
Network
TRON

Every reference page on this site is generated from docs/openapi.yaml, so it cannot drift from the running service.

What you can build

One key, four rails

Wallets

Users and deposits

Every user gets one permanent TRON address. The platform watches it, waits out confirmations, and credits a double-entry ledger. Deposits are free.

Read the guide

Payouts

Payouts

Quote the exact fee, then pay out to any address with an idempotency key. The outcome arrives as a webhook and is confirmed by the read.

Read the guide

Markets

Swap and exchange

Trade between assets a user already holds, or sell one and pay any of thousands of other coins out to an external address.

Read the guide

Spending

Card issuing

Issue crypto debit cards to your users and fund them straight from the custodial balance. Cards settle in USDT and are issued funded.

Read the guide

Quickstart

From a new user to a paid-out balance

The short version. The full Quickstart adds the webhook, the deposit event, the fee quote and the read that confirms a payout — six calls, copy-paste.

  1. 1

    Create a user

    Idempotent on your own external_user_id — a number of 5 to 10 digits. You get the user's Static Wallet Address back, and it never rotates.

    bash
    curl -sX POST https://api.cryptoinfra.build/v1/users \
  -H "Authorization: Bearer $CRYPTOINFRA_KEY" \
  -H "Content-Type: application/json" \
  -d '{"external_user_id":"10482"}'
  2. 2

    Read the balance

    Balances are ledger positions, not chain reads. What you get back is always spendable and always net of holds. A deposit is credited in full.

    bash
    curl -s https://api.cryptoinfra.build/v1/users/10482/balances \
  -H "Authorization: Bearer $CRYPTOINFRA_KEY"
  3. 3

    Pay out

    Quote it first with GET /v1/withdrawal-fee-quote. Every money mutation carries an idempotency_key, and a retry reuses it. You get 202; the outcome arrives as a webhook and is confirmed by the read.

    bash
    curl -sX POST https://api.cryptoinfra.build/v1/withdrawals \
  -H "Authorization: Bearer $CRYPTOINFRA_KEY" \
  -H "Content-Type: application/json" \
  -d '{"external_user_id":"10482","asset_id":"usdt_trc20",
       "to_address":"TJYBSfZfwwa28mYZPkE9uodBwGbnwEqBK1","amount":"25",
       "idempotency_key":"payout-8814"}'

The base URL is https://api.cryptoinfra.build and every /v1 endpoint takes your merchant key as a bearer token. Start with Introduction and Authentication, then the guide for the flow you are building; Money and amounts and Idempotency are the two things an integration gets wrong first.

Built to be read by machines

Point your assistant at the docs

The whole corpus is available as llms.txt, as one Markdown file, and as structured JSON. There is also a public, read-only MCP server, so an assistant can search and read these pages itself instead of you pasting them in.

AI integration llms-full.txt

Everything else

The full table of contents

Start here

Integrate

Conventions

Pricing

Resources

API reference