Endpoint inventory
This inventory reflects the methods, paths, and example field names in the supplied client Postman collection. All paths are relative to https://api.xdc.tech/v1.
Using this reference
This is an endpoint inventory, not an exhaustive payload schema. The deployed release has scoped authorization; selected public read and denial checks passed. The complete set of write requests has not been exercised as part of the onboarding read checks. Confirm required fields, route eligibility and payment behavior for your organization. An example field does not establish that it is required, optional, exhaustive, or valid for every route. No live request runner is provided.
{walletId}, {virtualAccountId}, {externalAccountId}, and {corridorId} below stand for identifiers belonging to your own organization or an approved route. The download uses Postman variables for them. Apart from GET /health, requests inherit X-Api-Key authentication in the source collection.
Required permissions
Every authenticated operation requires an eligible business and a reviewed key with read. Wallet creation, recipient administration and deposit-account deactivation additionally require resources:write. Transfers, payouts and payment routes require payments:write. Deposit-account creation/reactivation requires both write scopes. Explicit sync=true requires resource permission. See credentials and access.
Status
| Method | Path | Purpose |
|---|---|---|
GET | /health | Check reachability; no API key required. |
GET | /me | Inspect the customer associated with the key. |
Start with the quickstart. A health response does not confirm eligibility or permissions.
Wallets
| Method | Path | Purpose | Review level |
|---|---|---|---|
GET | /wallets | List wallets. | Read |
GET | /wallets/{walletId}/balance | Read wallet balance. | Read |
GET | /wallets/{walletId}/history | Read wallet history. | Read |
POST | /wallets | Create a wallet. | Changes account state |
The create-wallet example contains a chain body field. Supported values and organization eligibility are not established by this inventory.
Deposit accounts
The source calls these virtual accounts.
| Method | Path | Purpose | Review level |
|---|---|---|---|
GET | /virtual-accounts | List deposit accounts. | Read |
POST | /virtual-accounts | Create a deposit account. | Changes account state |
POST | /virtual-accounts/{virtualAccountId}/deactivate | Deactivate a deposit account. | Changes account state |
POST | /virtual-accounts/{virtualAccountId}/reactivate | Reactivate a deposit account. | Changes account state |
The create-account example contains source_currency, destination_currency, destination_payment_rail, and destination_address. Confirm supported currency/rail combinations and the correct destination before use.
Recipients
The source calls these external accounts.
| Method | Path | Purpose | Review level |
|---|---|---|---|
GET | /external-accounts | List recipients. | Read |
GET | /external-accounts/{externalAccountId} | Retrieve a recipient. | Read |
POST | /external-accounts | Create a recipient. | Changes account state |
PATCH | /external-accounts/{externalAccountId} | Update a recipient. | Changes account state |
POST | /external-accounts/{externalAccountId}/deactivate | Deactivate a recipient. | Changes account state |
POST | /external-accounts/{externalAccountId}/reactivate | Reactivate a recipient. | Changes account state |
The create-recipient example contains corridor_id, account_owner_name, bank_name, account_number, routing_number, street_line_1, city, state, postal_code, and country. The update example contains only account_owner_name; this is not a statement that other fields can or cannot be updated.
Treat beneficiary and banking details as sensitive. Confirm corridor-specific requirements before entering data.
Deposits
| Method | Path | Purpose |
|---|---|---|
GET | /deposits | List deposit activity. |
There is no deposit-creation request in this client collection.
Transfers
| Method | Path | Source request name | Review level |
|---|---|---|---|
GET | /transfers | List transfers. | Read |
POST | /transfers | Send to recipient (off-ramp). | Payment operation |
POST | /transfers/crypto-to-crypto | Crypto to crypto. | Payment operation |
POST | /transfers/payment-route | Crypto payment route. | Route configuration |
POST | /transfers/offramp-route | Off-ramp payment route. | Route configuration |
Source example body fields:
| Path | Fields present in the example |
|---|---|
/transfers | wallet_id, external_account_id, amount, source_currency, corridor_id |
/transfers/crypto-to-crypto | wallet_id, amount, source_currency, destination_currency, destination_payment_rail, destination_address |
/transfers/payment-route | wallet_id, source_currency, destination_payment_rail, destination_currency, destination_address |
/transfers/offramp-route | wallet_id, corridor_id, external_account_id, source_currency |
The source list request also includes a limit query parameter with example value 50. Valid ranges, defaults, pagination behavior, and completion statuses are not specified here.
Payouts
| Method | Path | Purpose | Review level |
|---|---|---|---|
GET | /payouts | List payouts. | Read |
POST | /payouts | Create a payout. | Payment operation |
The create-payout example contains wallet_id, amount, currency, beneficiary_name, beneficiary_account, beneficiary_routing, and destination_type. Confirm field semantics, route availability, approvals, and settlement behavior before use.
FX and corridors
| Method | Path | Source request name | Source query fields |
|---|---|---|---|
GET | /fx/latest | FX latest | None shown |
GET | /fx/rate | FX rate | from, to, amount |
GET | /corridors | Corridors | None shown |
The FX-rate source example uses from=USD, to=EUR, and amount=100. Those are example inputs, not a guarantee of supported currencies, an executable quote, or a fee/timing commitment. The client download replaces these values with empty variables. Confirm route eligibility before transacting.
Provider synchronization
The supplied collection adds sync=true to the list requests for wallets, deposit accounts, recipients, deposits, and transfers. The onboarding guide identifies this as requesting provider synchronization.
The client download and starter examples remove that parameter from all default list requests. Confirm its released behavior and required authority before adding it. Omitting synchronization does not establish data freshness or consistency guarantees.
Review before any write
All POST and PATCH requests require separate review before use. Establish organization eligibility, exact field validation, permission checks, and any approval requirements first. For payment operations, agree status reconciliation and retry handling; do not infer idempotency or final settlement from a successful HTTP response.
Download the sanitized client collection to inspect its request structure. It contains no live credentials, populated customer identifiers, or saved response data.