> ## Documentation Index > Fetch the complete documentation index at: https://docs.dakota.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Preview net receipt on an existing incoming SWIFT account > Returns an indicative estimate for an enabled foreign-currency SWIFT onramp owned by the authenticated client. The account determines the input currency and destination token/network; only the source amount is supplied. The estimated net amount includes the developer fee deducted from proceeds. Client invoice charges are not deducted. This read creates no account, transaction, fixed quote or credit hold. Final bank execution and settlement-time pricing determine delivery; valid_until denotes data freshness, not a rate lock. ## OpenAPI ````yaml /openapi.yaml post /accounts/{account_id}/incoming-fx-estimate openapi: 3.0.3 info: title: Dakota Platform API version: 1.0.0 description: >- Combined API specification for Dakota Platform services: - Issuance API: Asset minting and burning operations - Onboarding API: Know Your Business/Customer verification - On/Off Ramp API: Managing on-ramp and off-ramp accounts - Recipients API: Managing destinations for KYB'd entities - Transactions API: Viewing transaction history across platform operations ## Authentication and API Headers All API endpoints require the following headers: - `X-Idempotency-Key`: Required for all POST endpoints to ensure request idempotency - `x-api-key`: Required for authentication across all endpoints Note: On /applications endpoints you need a token for authentication instead of a x-api-key - `x-application-token`: Required for authentication on public /applications endpoints (alternative to `x-api-key` where documented) ## Rate Limits Requests are rate limited per API key. Every response includes the following headers: | Header | Description | | --- | --- | | `X-RateLimit-Limit` | Maximum requests allowed in the current one-minute window. | | `X-RateLimit-Remaining` | Requests remaining in the current window. | | `X-RateLimit-Reset` | Absolute Unix timestamp (seconds since epoch) when the current rate-limit window resets. | When a request is throttled (`429`), responses also include `Retry-After` with seconds to wait before retrying. servers: - url: https://api.platform.dakota.xyz description: Production environment - url: https://api.platform.sandbox.dakota.xyz description: Sandbox — safe for testing with simulated data security: - ApiKeyAuth: [] tags: - name: Agentic Payments x-beta: true description: >- Beta — agent-driven payments: provision agents, draft and approve spending mandates, accept reviewed instructions, and manage scheduled payments. **Prerequisites:** Customer onboarded; signer groups attached for recognition. **Related:** Wallets, Signer Groups, Transactions - name: Mandates x-beta: true description: >- Beta — spending mandates: signed, signer-bound authorizations governing what may be spent, approved or cancelled by a second recognized signer (§8 — the dual-control rule that every mandate mutation must be signed by a recognized signer OTHER than the bound one). Independent of agents and scheduled payments. **Prerequisites:** Signer groups attached for recognition. **Related:** Signer Groups, Transactions - name: Insights x-beta: true description: >- Beta — read-only insight: a deterministic report over a customer's agentic activity (funding balances, upcoming obligations, failures, mandate headroom and expiry), or — via `GET /insights` — over the whole client's book, with portfolio KPIs, daily series and a per-customer roll-up. Never moves money, never creates or changes anything. **Prerequisites:** Customer onboarded; insight is computed from the customer's scheduled payments, mandates, and wallets. **Related:** Agentic Payments, Mandates - name: Customers description: >- Manage customer entities representing businesses and organizations onboarded to Dakota. **Prerequisites:** Complete KYB via Onboarding endpoints before initiating money movement. **Related:** Onboarding, Recipients, Transactions, Accounts, Wallets - name: Wallets description: >- Manage wallets, balances, and wallet-to-signer-group relationships for custody and movement controls. **Prerequisites:** Customer must exist. Configure signer groups before policy-enforced workflows. **Related:** Signer Groups, Policies, Transactions, Customers - name: Transactions description: >- Create, cancel, and retrieve transaction records across account and wallet flows. **Prerequisites:** Accounts or destinations must be configured based on flow type. **Related:** Accounts, Recipients, Policies, Events - name: Recipients description: >- Manage recipient entities and destination rails used by customers for payouts and transfers. **Prerequisites:** Customer must be onboarded and active. **Related:** Customers, Transactions, Accounts, Onboarding - name: Cards description: >- Issue and manage cardholders and cards, and follow card transactions. Every change is also delivered as a webhook event. **Prerequisites:** Customer must be onboarded and the cards capability must be available. **Related:** Customers, Wallets, Events ### Webhook event catalog (v1) Every card-family event a client can subscribe to, in one place: | Event | Fires when | | -- | -- | | `cardholder.created` | A cardholder is created. | | `cardholder.updated` | Any cardholder change, including every review-status transition and deletion (`status: closed`). | | `cardholder.information_requested` | A reviewer asks for more information; the payload lists the open requirements. Not yet emitted; the review pipeline that opens a request for information is still to land. | | `card.created` | A card is created. | | `card.updated` | Any card change: status, spend limit, last4, freeze sources. A close arrives here with `status: closed`. | | `card_transaction.created` | The first event for a transaction, normally an authorization (`status: authorized`) placing a hold. A declined authorization also arrives here, with `status: declined`. | | `card_transaction.updated` | Every later change to the same transaction (see below). | | `wallet.card_enablement.completed` | A wallet's card-settlement enablement became active. | **Card event ordering.** `card.created` and `card.updated` carry the card as it stands after the change, including `version` and `freeze_sources` (always an array, empty when nothing holds the card). `version` is strictly increasing per card and matches the `version` on the card resource. Deliveries can arrive out of order, so keep the highest `version` you have applied for each card and drop any event whose `version` is not greater than it. **One transaction stream.** Holds, releases, partial clearings, settlement, returns, disputes and force posts are not separate event types. They are `status` transitions on the transaction, delivered as `card_transaction.updated` with the same payload shape as `card_transaction.created`: | What happened | `status` on the event | | -- | -- | | Transaction known before its first authorization event | `pending` (on `card_transaction.created`) | | Hold placed (authorization) | `authorized` (on `card_transaction.created`, or `card_transaction.updated` after a `pending` start) | | Hold released without clearing (merchant, issuer or network reversal) | `auth_reversed` | | Hold expired unused | `expired` | | Part of the hold settled | `partially_cleared` (with the new `cleared_amount`) | | Fully settled | `cleared` | | Settled with no prior hold | `force_posted` | | Merchant refund | `returned`, on a new card transaction for the refund; the original purchase stays `cleared`. The network returned the money; read `refund_state` for whether it reached the customer's wallet (`pending` then `paid`). `returned` alone is not proof of payout. | | Chargeback opened | `disputed` (reserved; not emitted yet) | | Authorization refused | `declined` (on `card_transaction.created`, or `card_transaction.updated` when the transaction already exists). Moves no money; read `decline_reason` and `decline_code` for why. | `outstanding_amount` is the part of `cleared_amount` that no authorization covered, less any refunds: non-zero after a force post or an over-capture. **Naming.** A dotted segment names a sub-resource of the resource before it, so `wallet.card_enablement.*` is a wallet's card enablement. `card_transaction.*` carries an underscore because the resource is `card_transactions`, a top-level resource, not a sub-resource of a card. It is not a typo, and there is no `card.transaction.*` family, and no separate settlement event: settlement is a `status` on `card_transaction.updated`. - name: Accounts description: >- Manage account resources used for onramp, offramp, and swap operations. **Prerequisites:** Customer must be created and network/asset constraints must be known. **Related:** Customers, Transactions, Auto Transactions, Info - name: Auto Transactions description: >- Manage automated transaction configurations and execution history for account automation workflows. **Prerequisites:** Source account must exist and be configured for automation. **Related:** Accounts, Transactions, Events - name: Onboarding description: >- Manage KYB/KYC onboarding lifecycle, application documents, attestations, and verification steps. **Prerequisites:** Customer context and required entity/application metadata. **Related:** Customers, Exceptions, Recipients, Transactions - name: Policies description: >- Define and manage policy objects and rules used for transaction governance and risk controls. **Prerequisites:** Wallet and signer group resources should be configured for enforcement scenarios. **Related:** Wallets, Signer Groups, Transactions - name: Signer Groups description: >- Manage signer groups and signer assignments for multi-party authorization models. **Prerequisites:** Wallets should exist before linking signer groups. **Related:** Wallets, Policies, Transactions - name: Authentication description: >- Manage API authentication credentials and key lifecycle for platform access. **Prerequisites:** Client organization must be provisioned. **Related:** Users, Info - name: Users description: >- Manage client users, roles, and identity metadata for platform access control. **Prerequisites:** Auth credentials and client context must be established. **Related:** Authentication - name: Webhooks description: >- Manage outbound webhook targets and delivery configuration for event notifications. **Prerequisites:** Subscriber endpoint must be reachable and secured. **Related:** Events, Authentication - name: Payouts description: >- Manage where Dakota sends your accrued developer-fee payouts. **Prerequisites:** Auth credentials and client context must be established. **Related:** Events - name: RD Marketing Fee description: >- Everything behind your RD marketing fee: read what a month came to, declare the wallets you hold outside Dakota so the RD in them counts, and say where the fee should be sent. **Prerequisites:** Client must be in the RD marketing-fee programme. A month is readable once it has closed. **Related:** Wallets, Events - name: Self Serve description: >- Buy and track prepaid credits, and read the tiers and pricing they are sold at. **Prerequisites:** Auth credentials and client context must be established. **Related:** Billing - name: Events description: >- Retrieve event records emitted by platform operations for audit and troubleshooting. **Prerequisites:** Requesting client must have access to referenced resources. **Related:** Webhooks, Transactions, Onboarding - name: Info description: >- Read platform capability metadata, such as supported rails, networks, and assets. These operations are served under `/capabilities/*` - `GET /capabilities/countries` and `GET /capabilities/networks`. The tag name does not appear in the request paths. **Prerequisites:** Valid authentication headers. **Related:** Accounts, Transactions - name: Sandbox description: >- Trigger sandbox-only simulation endpoints for safe end-to-end integration testing with synthetic data. The sandbox host (`https://api.platform.sandbox.dakota.xyz`) also accepts a family of `X-Sandbox-*` request headers on most write endpoints (`Customers`, `Accounts`, `Transactions`, simulate endpoints) that let integrators drive deterministic failure modes — pick a preset via `X-Sandbox-Scenario`, or compose a custom one with `X-Sandbox-Error-Step`/`X-Sandbox-Error-Status`/`X-Sandbox-Error-Message`. `X-Sandbox-Instant-Completion` collapses async flows to a single synchronous step, and `X-Sandbox-Skip-Auto-Approval` keeps newly created KYB applications in `pending` for manual-review testing. All `X-Sandbox-*` headers are ignored in production. **Prerequisites:** Sandbox environment and test customer data. **Related:** Customers, Accounts, Transactions, Onboarding - name: Legal description: |- The legal documents customers accept — terms of service, privacy policy, e-sign notice, and partner agreements. Dakota publishes these here, and this is the authoritative source: the hosted onboarding flow, the dakota.xyz website, and your own integration all read the same revisions. Present the current revision to your customer before capturing their acceptance so the record reflects the text they actually saw. paths: /accounts/{account_id}/incoming-fx-estimate: post: tags: - transactions summary: Preview net receipt on an existing incoming SWIFT account description: | Returns an indicative estimate for an enabled foreign-currency SWIFT onramp owned by the authenticated client. The account determines the input currency and destination token/network; only the source amount is supplied. The estimated net amount includes the developer fee deducted from proceeds. Client invoice charges are not deducted. This read creates no account, transaction, fixed quote or credit hold. Final bank execution and settlement-time pricing determine delivery; valid_until denotes data freshness, not a rate lock. operationId: estimateAccountIncomingFX parameters: - in: path name: account_id required: true schema: type: string requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/IncomingFXEstimateRequest' example: source_amount: '100' responses: '200': description: Indicative estimate; no account or financial state changed content: application/json: schema: $ref: '#/components/schemas/IncomingFXEstimate' example: account_id: 3JyvsbaOW929vLbatXEkrUMq1YC mode: indicative amount_state: estimated source_currency: EUR source_amount: '100' destination_asset: USDC destination_network: eip155:8453 destination_decimals: 6 estimated_gross_usd_amount: '118.4' estimated_net_usd_amount: '118.1' estimated_destination_amount: '118.1' estimated_destination_smallest_units: '118100000' developer_fee_usd: '0.3' developer_fee_bps: '25' developer_fee_fixed_usd: '0' valuation_usd_per_unit: '1' valuation_reference: provider:usd-dollar-fulfillment:v1 valuation_source: usd_fulfillment_policy valuation_policy_checked_at: '2026-09-29T04:00:00Z' rate_observed_at: '2026-09-29T03:59:00Z' estimated_at: '2026-09-29T04:00:00Z' valid_until: '2026-09-29T04:05:00Z' pricing_reference: bid pricing_rate: '1.19' customer_rate: '1.18405' spread_bps: '50' policy_version_id: 11111111-1111-4111-8111-111111111111 observation_id: 22222222-2222-4222-8222-222222222222 fee_basis: usd_deposit_fees_v1:developer_deducted:dakota_invoiced '400': description: Request refused or estimate unavailable '401': description: Request refused or estimate unavailable '403': description: Request refused or estimate unavailable '404': description: Request refused or estimate unavailable '409': description: Request refused or estimate unavailable '422': description: Request refused or estimate unavailable '503': description: Request refused or estimate unavailable components: schemas: IncomingFXEstimateRequest: type: object additionalProperties: false required: - source_amount properties: source_amount: type: string pattern: ^[0-9]{1,18}(\.[0-9]{1,2})?$ maxLength: 21 IncomingFXEstimate: type: object description: >- Read-only indicative net preview, without a hold or guaranteed rate. Valid until denotes freshness only. required: - account_id - mode - amount_state - source_currency - source_amount - destination_asset - destination_network - destination_decimals - estimated_gross_usd_amount - estimated_net_usd_amount - estimated_destination_amount - estimated_destination_smallest_units - developer_fee_usd - developer_fee_bps - developer_fee_fixed_usd - valuation_usd_per_unit - valuation_reference - valuation_source - rate_observed_at - estimated_at - valid_until - pricing_reference - pricing_rate - customer_rate - spread_bps - policy_version_id - observation_id - fee_basis properties: account_id: type: string mode: type: string enum: - indicative amount_state: type: string enum: - estimated source_currency: type: string source_amount: type: string destination_asset: type: string destination_network: type: string destination_decimals: type: integer minimum: 1 maximum: 18 estimated_gross_usd_amount: type: string estimated_net_usd_amount: type: string estimated_destination_amount: type: string estimated_destination_smallest_units: type: string developer_fee_usd: type: string developer_fee_bps: type: string developer_fee_fixed_usd: type: string valuation_usd_per_unit: type: string valuation_reference: type: string valuation_source: type: string enum: - usd_fulfillment_policy - rd_redemption_policy - market rate_observed_at: type: string format: date-time estimated_at: type: string format: date-time valid_until: type: string format: date-time pricing_reference: type: string pricing_rate: type: string customer_rate: type: string spread_bps: type: string policy_version_id: type: string observation_id: type: string fee_basis: type: string valuation_observed_at: type: string format: date-time valuation_policy_checked_at: type: string format: date-time securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key ````