Quickstart

Start with an authenticated sandbox call, then prepare the payer and complete a signed payment. The API Reference defines exact request and response shapes.

All examples target the sandbox base URL https://sandbox-api.xkova.com/v1. The production base URL is https://api.xkova.com/v1. Sandbox API keys are prefixed xkv_test_.

1. Get a sandbox API key

Sign up in the management Console to create your sandbox workspace, then create an API key with the permission families your server needs. Production access requires separate approval. Sandbox keys carry the xkv_test_ prefix and authorize tenant scoped calls.

2. Make your first authenticated call

Every authenticated request sends the key as a bearer token. Confirm your key and scopes:

curl -s https://sandbox-api.xkova.com/v1/me/scopes \
  -H "Authorization: Bearer $XKOVA_API_KEY"

Read the authenticated automatic chain and asset catalogs. They contain the active testnet networks and assets available to this sandbox workspace:

curl -s https://sandbox-api.xkova.com/v1/chains/available \
  -H "Authorization: Bearer $XKOVA_API_KEY"

curl -s https://sandbox-api.xkova.com/v1/workspace-tokens \
  -H "Authorization: Bearer $XKOVA_API_KEY"

3. Follow the path to a first payment

A single call does not move money. A confirmed payment depends on a small amount of one time setup, then a signed transfer that the XKOVA Relayer submits and XKOVA confirms on chain. The Console checklist helps prepare the workspace; permission, compliance, asset eligibility, and signing checks still apply.

Step	What it does
Create an API key	A sandbox key for server to server calls.
Review fees and policy	Use workspace pricing and the sandbox screen-and-cap policy. Custom fee schedules require revenue controls; earned rules also require a revenue treasury.
Provision an account holder	Prepare the session-bound payer, meet the committed identity and consent policy, provision the wallet, and confirm sandbox funding.
Create the payment	The member signs an EIP-712 intent, the XKOVA Relayer submits it, and XKOVA confirms it on chain.

When you create the payment, choose a rails-eligible asset whose direct-send flow is certified from GET /v1/workspace-tokens. This is an operation choice, not workspace configuration.

When API key creation is governance held: the call returns status: pending_approval with a pending_approval_request_id, the workspace owner attests it in the console under Governance, Approvals (or via the attestation operations), and re-submitting the same call mints the key. Committing the value-movement authorization policy is held the same way; committing a fee schedule is not. See Policies and Quorum Governance for the approval baseline.

The signing step is what makes the system non-custodial. The member signs the transfer in their own wallet. XKOVA never holds member keys. See the Platform Overview for the model.

4. Where to go next

API Reference for the exact shape of every operation.
Developer Guide pages for authentication, idempotency, pagination, errors, rate limits, and webhooks.
SDK Reference for the TypeScript client and the workflow methods.

Was this helpful?