API Surface
A capability-level inventory of the KryptoGO partner-facing API surface. This is not the API reference — that lives at the API Reference section. This page exists so you can scope, in a planning conversation, which capabilities are reachable through which auth model.
Two backends, two authentication patterns
| Backend | Domain | Auth pattern | What lives here |
|---|---|---|---|
| Core platform | wallet.kryptogo.app | Studio session token (web), API key (server-to-server), or OAuth 2.0 (federated) | Payments, invoices, payouts, custody (Asset Pro), KYB and KYC, organisation and team management, AML risk scoring |
| Data platform | wallet-data.kryptogo.app | Header-based identification for analytics consumption; partnership-scoped credentials for enterprise use | On-chain analytics — wallet labels, balance histories, top holders, signals, address risk |
Most partner integrations use the core platform. The data platform is reserved for analytics and research use cases.
Server-to-server API key — what an enterprise partner can call
When you hold a Studio API key (issued through the Studio control panel, scoped to your organisation), the following capability groups are callable via the X-STUDIO-API-KEY header. Detailed request and response schemas live in the API Reference section.
Wallet provisioning
| Capability | Description |
|---|---|
| Get organisation addresses | Returns the organisation’s automatically-provisioned wallet addresses across supported chains |
| Create user with deterministic seed | Provisions a user wallet whose address is derived from a partner-supplied identifier; useful for embedded-self-custody scenarios where the partner needs to know addresses ahead of first user touch |
Payment intents
| Capability | Description |
|---|---|
| Create payment intent | Originates a single payment lifecycle on a chosen chain and stablecoin |
| Get payment intent | Fetches the current state and history of a specific intent |
| Cancel payment intent | Cancels a pending intent that has not yet settled |
| List payment intents | Paginated listing for reconciliation jobs |
| Quote payment intent | Returns the crypto-amount equivalent for a given fiat-amount, useful for previewing prices to the customer |
Payment-intent state changes trigger HMAC-SHA256-signed callbacks to the URL configured at intent creation, with a five-minute timestamp validity window. Verify the signature in the payload body before acting.
Custodial transfers (Asset Pro)
| Capability | Description |
|---|---|
| Submit transfer | Initiates a custodial transfer that enters the Maker / Approver / Signer multi-signature workflow |
| Multi-sig approval and release | Approver and Signer actions, also exposed through the Studio control panel |
Transfer status today is queryable through the Studio control panel by your operations team. Programmatic transfer-history retrieval and push-based webhook callbacks for transfer status are on the near-term roadmap; if you need them on day one, flag during scoping.
Address risk and AML screening
| Capability | Description |
|---|---|
| Risk-assess address | Inline address-level AML risk scoring; rate-limited per organisation |
Compliance
| Capability | Description |
|---|---|
| Issue compliance token | Issues a short-lived compliance token used by KYB / KYC flow surfaces |
Studio session token — for in-Studio operations
The Studio control panel itself uses a session token (the Kg-Studio-Token-V2 header) when your operations team is logged in. Today the following are operated through Studio rather than via API key, with a programmatic API extension on the near-term roadmap:
- Invoice creation, multi-step approval, and signing
- Payout intent creation, approval, and signing
- Refund initiation
- Custodial transfer history and operator counters
If your scenario needs any of these accessible programmatically, raise it during scoping — the path forward is well understood.
OAuth 2.0 — for federated partner-app integrations
Partners offering “Sign in with KryptoGO” or building user-facing apps that authenticate against KryptoGO use the OAuth 2.0 flow. See Sign-In with KryptoGO for detail.
Mobile Wallet SDK — method-channel surface
The Mobile Wallet SDK communicates with the partner’s native iOS or Android host application through a method-channel bridge. The partner-callable surface includes:
| Method | Description |
|---|---|
init | Initialises the SDK with a partner client ID and a JWT identifying the end user |
isReady, checkDevice, isWalletCreated | State queries used by the partner app to render the right UI |
getBalance | Returns the user’s total balance in USD-equivalent |
openView | Navigates the SDK’s embedded UI to specific screens (receive, send, swap) |
refreshSharedSecret | Triggers a refresh of the SSS key share held by the partner cloud |
The partner host receives callbacks for events the SDK cannot complete on its own — primarily, requests to read or write the partner-cloud SSS share, and requests to open transaction-verification UI.
Webhook delivery — what we POST to your endpoints
| Event family | Status | Signing | Replay protection |
|---|---|---|---|
| Payment-intent state changes | Shipped | HMAC-SHA256 in payload body | Five-minute timestamp validity window |
| Custodial transfer state changes (Asset Pro) | On near-term roadmap | Will use the same signing scheme | Same five-minute window planned |
| KYC / KYB state changes | Available on partnership scoping | Same signing scheme | Same window |
Your handler should: (1) verify the signature against the canonical payload using the shared secret, (2) respond 200 to acknowledge, (3) treat the callback as idempotent — the same state change can fire more than once on retry paths.
Where to go next
- Architecture Overview — for the system-level picture.
- SDK Distribution — for what is published on npm versus delivered through partnership.
- Glossary — for plain-English definitions of the terms used here.
- For full request and response schemas, see the API Reference section.