Credentials and access

Release status

The portal supports business-specific API-key administration, separate permission scopes, one-time secret display and revocation. Your business must be eligible and your login explicitly authorized before key controls are available.

Before you start

Complete business verification with XDC Tech, confirm your integration's required capabilities, and activate your portal account. An authorized XDC administrator must explicitly assign your login the API-key administrator membership for your business. Matching email addresses do not establish this permission. A platform staff account is not a client key-creation account.

One primary client login can manage keys with different permissions for different integrations. Your portal login identifies a person; an API key authenticates software. Payment-enabled API requests do not require someone to approve each request in the portal. Protect those keys accordingly.

Production base URL: https://api.xdc.tech/v1. This is a live environment, not a sandbox. Confirm any separate test environment with your onboarding contact before using it.

Choose permissions

Every key includes read access. Select additional permissions to match the integration agreed during onboarding; a payment integration does not have to begin with a read-only key. Its first verification requests should nevertheless be reads.

Portal choice	API scope	What it allows
Read account data	read	Customer identity, balances, activity, recipients, FX and corridor reads
Create payments and payment routes	payments:write	Supported transfers, payouts and payment routes
Manage resources	resources:write	Wallet creation, recipient management, deposit-account deactivation and explicit provider synchronization
Both write choices	Both write scopes plus read	Deposit-account creation and reactivation, which establish or resume payment routing

Read plus payment access does not authorize creating wallets or managing recipients. Arrange those resources separately or agree resource-management access. A scope does not override account eligibility or provider restrictions, and it never grants access to another business.

Create and store a key

1. Sign in to the portal and open Developers → API keys.
2. Select Business for API access and verify the organization. If none appears, ask your onboarding contact to arrange your explicit membership.
3. Under Create API key, enter a descriptive Key name and select Permissions.
4. Select Send confirmation code. Use the code delivered to your signed-in account's email. Verify the displayed business, name and permissions, then select Confirm & create. If you change the selection, start a new confirmation.
5. Store the full secret in your organization's secrets manager. Select Copy key, then I have stored it only after saving it. The full secret is shown once and cannot be retrieved later; subsequent listings are masked.
6. Follow the linked quickstart read requests and check that the returned business and permissions match your expectations.

An eligible business can have up to five active keys. Expired or exhausted confirmation attempts require a new confirmation. If the code fails repeatedly or the creation controls are absent, contact onboarding support; do not share the code or key.

Keep keys in backend services. Never embed them in browser/mobile application code, source control, chat, screenshots, logs, tickets, shared collections, or exported environments. XDC staff do not need the full secret to support your integration.

Revoke or replace a key

For a routine replacement, create a new key with the required permissions, update each dependent service's secret, verify a read request, then select Revoke beside the old masked key and confirm Revoke key. Verify that subsequent requests using the old key are rejected. Plan capacity first if all five key slots are occupied; do not revoke a working key blindly to free a slot.

To change permissions, create a replacement key rather than assuming the existing key can be edited. If a key is compromised, revoke it promptly and contact your onboarding representative. Revocation blocks subsequent authentication; an already accepted operation may finish. A lost secret must be replaced, not recovered.

Removing a person's API membership does not automatically revoke business integration keys they created. Review those keys separately when staff access changes. Creation/revocation notices do not contain the secret; a notification failure does not undo the action. If the portal reports a security-email problem, contact support.

Next: make your first requests.