Settings and Branding

Settings is where an operator configures the workspace itself: who is on the team, which API keys exist, how payments are priced, and how your brand appears to members. It opens with the four areas you will use most, then covers webhooks, integration gateways, production access, and billing.

Team

The team section lists every operator in the active tenant. Admins can invite a new operator, which sends a Login Link by email, resend an invite that has not yet been redeemed, and revoke access. Revoke is a soft action that flips the operator's state and is reversible by re-inviting. You cannot revoke your own access from the console; that guard is enforced by the API.

Revoking an operator can cascade. When a staff member is revoked, role grants they authorized for API keys are revoked too. Plan team changes with that in mind.

API keys

The API keys section issues and revokes the tenant's keys. A newly created key shows its secret exactly once, so copy it into your secret manager immediately. Sandbox keys are prefixed xkv_test_. Revoke is the normal way to retire a key; the audit trail of who revoked what and when is preserved.

Create. Name the key, optionally set an expiry, and optionally mark it for elevated actions. The secret appears once. On a fresh workspace the first creation is held for owner approval: the form shows a held notice, the owner attests under Governance, Approvals, and re-submitting the same form mints the key and shows the secret.
Scope and roles. A key carries the scopes and roles it needs. Role grants can be attached to an existing key without rotating its secret.
Revoke. Retire a key; it stops authorizing immediately.

For the auth model behind keys, see Authentication and Authorization and RBAC. Never ship an API key to a browser; keep it server side.

Fee schedules

A fee schedule prices the payments that flow through a workspace. A payment is rejected until a committed schedule exists for it, which is why committing one is on the onboarding checklist. Each schedule is per workspace, so the active workspace (sandbox or production) determines which schedule applies. The XKOVA platform fee is applied automatically to the enabled transaction types and is shown read only.

Build a draft schedule with rules for the transaction types you support.
Set the beneficiary for earned fees; a treasury vault can be picked directly.
Commit the schedule. Creating and committing are admin only.

A schedule that carries earned-fee rules (your own institution, external, or issuer fees) cannot commit unless the workspace has an active revenue treasury, because earned fees are routed to that treasury vault. Set up that vault first in Treasury.

Branding

Branding gives a tenant owner self-service control over how their brand appears on the member facing surfaces: sign-in emails, and the claim and signing pages. The console itself stays XKOVA branded; only the editor lives in settings. You set a brand name, colors for light and dark, a logo, and the term you use for members, then preview each surface live before saving. Saving is admin or owner gated.

Surface	What branding controls
Sign-in emails	The from name, brand name, and colors on the emails members receive.
Claim page	The look of the page a recipient uses to claim funds.
Signing page	The look of the page where a member previews and signs a transfer.

Approving held actions

Some actions are held pending a quorum of staff sign-off (the seeded defaults in Policies and Quorum Governance, plus any requirements the owner adds). The Approvals inbox under Governance lists every open request with its live signature count per clause and an owner-attestation flag where one is required. Approving means connecting your in-app signing wallet and signing an approval message; there is no separate password or code. Once enough staff have signed, the request flips to ready and the original held action is re-submitted from its own page to complete. Cancelling a request abandons the pending approval only; it does not undo or clear the resource that was waiting on it.

Webhooks

The Webhooks area manages the endpoints XKOVA delivers events to. Create an endpoint with its URL and the event types it subscribes to; the signing secret is shown exactly once at creation and once at each rotation, so store it immediately. From the same page you can enable or disable an endpoint, send a signed test event to confirm the wiring, and delete an endpoint (irreversible). Each endpoint has a delivery log with per-delivery diagnostics, and failed deliveries can be replayed one at a time or in bulk. Secret rotation keeps the old secret valid through a short overlap window so you can cut over without dropping events. For the delivery format and verification, see Webhooks.

Integration gateways

A tenant that runs its own backend gateways (for example the core-banking gateway from Core Banking) registers them here by name and base URL, and pins the gateway's TLS certificate fingerprint so XKOVA trusts only that exact certificate; rotate the pin when the certificate changes. A gateway can be enabled or disabled, shows a conformance status from the automated conformance run, and keeps a per-gateway log of the calls it has made.

Production access

Moving from sandbox to production is a gated request, not a toggle. The Production access section shows a checklist of gates: an active production workspace entitlement, a billing customer on a chargeable plan, an active subscription, a manual finance approval on XKOVA's side, and a production network that is live for payments on this XKOVA environment (a platform-side gate you cannot action; contact XKOVA if it is blocking). When the self-service gates are clear, submit the request from this page and track it to approval or rejection; the decision is recorded with a note in the audit trail.

Billing and usage

The Billing section is the read side of what the workspace owes and uses: the current subscription and its plan, invoice history, and a link out to a hosted portal for managing payment methods. It also reports the on-chain platform fees the tenant has paid per token (with a downloadable accrual log) and a USD ramp volume aggregate for a date range that mirrors what invoicing bills against, with production-billable activity separated from sandbox activity. This surface is read-only reporting; what a tenant charges on its own payments is the fee schedule above.

Settings also covers workspaces and enabled tokens, and member authentication configuration. For the exact operations, see the operations list or the interactive reference. For the roles that gate these actions, see Roles and Permissions.

Was this helpful?