Quickstart

This page takes you from zero to your first authenticated call, then outlines the short path to a confirmed sandbox payment. It is an agent written guide. The exact request and response shapes for every endpoint live in the API Reference.

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

Create a tenant in the operator console and generate a sandbox key, or call the signup surface directly if you are testing the API. 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 xkv_test_..."

One public route does not need a key, because signup needs it first. Use it to read the chain registry and find the sandbox chain reference:

curl -s https://sandbox-api.xkova.com/v1/chains

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 same five gates appear on the console onboarding checklist.

Step	What it does
Create an API key	A sandbox key for server to server calls.
Enable a token	Add a permit supporting token, for example sandbox USDC, to the workspace allowlist.
Commit a fee schedule	Set the fee rules for the send context so a payment can price itself.
Provision an account holder	Create the member who will sign and hold balances.
Create the payment	The member signs an EIP-712 intent, the XKOVA Relayer submits it, and XKOVA confirms it on chain.

On a fresh workspace the first 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 seeded 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?