> ## 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. # Get details of a specific auto account transaction > Retrieves a single auto-transaction record by `auto_transaction_id` with execution details and status. ## OpenAPI ````yaml /openapi.yaml get /auto-transactions/{auto_transaction_id} 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: /auto-transactions/{auto_transaction_id}: get: tags: - Auto Transactions summary: Get details of a specific auto account transaction description: >- Retrieves a single auto-transaction record by `auto_transaction_id` with execution details and status. operationId: getAutoTransaction parameters: - name: auto_transaction_id in: path required: true description: Unique identifier of the auto account transaction schema: $ref: '#/components/schemas/KSUID' responses: '200': description: Auto account transaction details content: application/json: schema: $ref: '#/components/schemas/AutoAccountTransaction' example: id: 1NFHrqBHb3cTfLVkFSGmHZqdDPi client_id: 1NFHrqBHb3cTfLVkFSGmHZqdDPi auto_account_id: 1NFHrqBHb3cTfLVkFSGmHZqdDPi destination_id: 1NFHrqBHb3cTfLVkFSGmHZqdDPi type: onramp status: timed_out failure_reason: string created_at: 1234567890 updated_at: 1234567890 completed_at: 1234567890 receipt: imad: string omad: string input: amount: string asset: string network: string subtotal: amount: string asset: string network: string converted: amount: string asset: string network: string output: amount: string asset: string network: string exchange_rate: string external_fee: amount: string asset: string network: string dakota_fee: amount: string asset: string network: string client_fee: amount: string asset: string network: string developer_fee: amount: string asset: string network: string gas_fee: amount: string asset: string network: string payment_reference: Invoice payment for services crypto_details: source_crypto_address: string source_network_id: ethereum-mainnet destination_crypto_address: string destination_network_id: ethereum-mainnet deposit_transaction_hash: string transaction_hash: string provider_id: dakota provider_external_id: txn_123456789 provider_status: processing '400': description: Invalid request content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' example: type: https://docs.dakota.xyz/api-reference/errors#invalid-request title: Invalid request status: 400 detail: Invalid request instance: https://api.platform.dakota.xyz/auto-transactions/example-id request_id: req_01hzy6y7v8w9x0y1z2a3b4c5d6 '401': description: Unauthorized content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' example: type: >- https://docs.dakota.xyz/api-reference/errors#authentication-error title: Unauthorized status: 401 detail: Unauthorized instance: https://api.platform.dakota.xyz/auto-transactions/example-id request_id: req_01hzy6y7v8w9x0y1z2a3b4c5d6 '403': description: Forbidden content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' example: type: https://docs.dakota.xyz/api-reference/errors#forbidden title: Forbidden status: 403 detail: Forbidden instance: https://api.platform.dakota.xyz/auto-transactions/example-id request_id: req_01hzy6y7v8w9x0y1z2a3b4c5d6 '404': description: Not found content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' example: type: https://docs.dakota.xyz/api-reference/errors#not-found title: Not found status: 404 detail: Not found instance: https://api.platform.dakota.xyz/auto-transactions/example-id request_id: req_01hzy6y7v8w9x0y1z2a3b4c5d6 externalDocs: description: Read full guide in docs url: >- https://docs.dakota.xyz/api-reference/auto-transactions/get-details-of-a-specific-auto-account-transaction components: schemas: KSUID: type: string title: KSUID description: >- KSUID is a 27-character globally unique ID that combines a timestamp with a random component. Used for all entity identifiers in the Dakota platform. pattern: ^[0-9A-Za-z]{27}$ minLength: 27 maxLength: 27 example: 1NFHrqBHb3cTfLVkFSGmHZqdDPi AutoAccountTransaction: type: object description: A transaction relating to an auto account required: - id - client_id - auto_account_id - destination_id - type - provider_id - provider_external_id - provider_status - status - created_at - updated_at properties: fx_outgoing_amounts: type: object additionalProperties: true description: >- Version 1 foreign outgoing amount_state unknown, with exact known source amount/currency and destination currency. Not a quote. fx_settlement: type: object additionalProperties: true description: >- Version 1 verified outgoing native settlement and bank payout evidence. Absent is unknown. fx_amounts: type: object description: >- Versioned incoming FX evidence; v2 allows an unknown original foreign amount independently of exact settled USD and net token output. additionalProperties: true id: $ref: '#/components/schemas/KSUID' client_id: $ref: '#/components/schemas/KSUID' auto_account_id: $ref: '#/components/schemas/KSUID' destination_id: $ref: '#/components/schemas/KSUID' type: $ref: '#/components/schemas/TransactionType' status: $ref: '#/components/schemas/TransactionStatus' failure_reason: type: string description: >- Dakota's explanation of why the transaction failed, present if status is 'failed'. Descriptive text for display; use `failure_code` for logic. failure_code: $ref: '#/components/schemas/TransactionFailureCode' created_at: type: integer description: Unix timestamp when the transaction was created. example: 1234567890 updated_at: type: integer description: Unix timestamp when the transaction was last updated. example: 1234567890 completed_at: type: integer description: Unix timestamp when the transaction was completed. example: 1234567890 receipt: $ref: '#/components/schemas/TransactionReceipt' crypto_details: $ref: '#/components/schemas/TransactionCryptoDetails' sender_details: $ref: '#/components/schemas/SenderDetails' provider_id: type: string description: Provider identifier example: dakota provider_external_id: type: string description: Provider external transaction identifier example: txn_123456789 provider_status: type: string description: Status reported by provider example: processing return_code: type: string description: >- Return code (e.g., R01) when the transaction was returned by the receiving bank. NACHA/Fedwire codes for US bank rails; international (SWIFT) wire returns carry no NACHA code and may return a reduced amount after intermediary fees. A return can arrive with no code; `failure_code` is still set (to `payment_returned`). Cleared if the transaction later completes. example: R01 return_reason: type: string description: >- Dakota's explanation of why the payment was returned. Descriptive text for display; use `failure_code` for logic. example: The recipient account could not be found. return_initiated_at: type: integer description: Unix timestamp when the return was initiated. example: 1234567890 return_deadline: type: integer description: Unix timestamp deadline for return processing. example: 1234567890 net_recovered_amount: type: string nullable: true description: >- Decimal amount recovered when a returned payout came back short and the customer bore the deduction, denominated in the transaction's own currency (the same basis as its face amount), so face amount minus this value is what the customer went without. Present only in that case; it never means zero. It is set once the refund to the source wallet has been sized. It is absent on `pending_return` and `returned` whatever came back, can first appear on `pending_reversal`, and stays on `reversed`. After the refund is sized, absence means the customer was refunded the face amount in full, because the whole amount came back, Dakota absorbed the bank's deduction (a refund made before the bank reported what it returned), or the rail reports no net figure (ACH never does). Cleared, like the other return fields, if the payout later completes (for example a returned wire that was resent and delivered). example: '24955' reversal_reason: type: string description: >- ACH reversal reason when the originator reverses the transaction (e.g., duplicate, receiver_incorrect). Cleared if the transaction later completes (the bank rejected the reversal). example: duplicate reversal_initiated_at: type: integer description: >- Unix timestamp when the reversal was initiated. Cleared if the transaction later completes (the bank rejected the reversal). example: 1234567890 ProblemDetails: type: object required: - type - title - status description: | Error response following RFC 9457 Problem Details. Public API error responses use this format. example: type: https://docs.dakota.xyz/api-reference/errors#not-found title: Customer Not Found status: 404 detail: Customer cst_2abc123 was not found in your organization. instance: https://api.platform.dakota.xyz/customers/cst_2abc123 request_id: req_7f3a8b2c properties: type: type: string format: uri description: | URI reference identifying the problem type. Resolves to human-readable documentation. example: https://docs.dakota.xyz/api-reference/errors#not-found title: type: string description: >- Short, human-readable summary of the problem type. Stable across occurrences. example: Customer Not Found status: type: integer description: HTTP status code for this occurrence. example: 404 detail: type: string description: Human-readable explanation specific to this occurrence. example: Customer cst_2abc123 was not found in your organization. instance: type: string format: uri description: The request path that triggered this error. example: https://api.platform.dakota.xyz/customers/cst_2abc123 request_id: type: string description: Unique request identifier. Include when contacting support. example: req_7f3a8b2c errors: type: array description: Field-level validation errors (present for validation failures). items: $ref: '#/components/schemas/ValidationError' resolution_url: type: string format: uri description: | A link the customer can follow to CLEAR this error, present only on problems with a concrete self-service remedy. Today this is returned by `#terms-not-accepted`, where it points at the hosted flow in which the outstanding agreement can be signed. The link is token-gated and usable as-is — send the customer to it directly rather than parsing it out of `detail`. example: >- https://onboarding.dakota.xyz/applications/2abc123?token=tok_7f3a8b2c user_message: type: string description: | A plain-language rendition of `detail` written for the end customer, present when one exists for this error. `detail` names request fields and actions so a machine caller (such as a payment agent drafting proposals) can self-correct; `user_message` says the same thing without API vocabulary. Clients that relay errors into a human surface (chat, email, UI) should show `user_message` when present and fall back to `detail`. example: >- ACH payments pay out USD, so a USDC payout isn't possible on this rail. Change the payout currency to USD and try again. reason: type: string description: > A stable, machine-readable code for why the request was refused, present only when Dakota has a typed reason for this error. Branch on `reason` rather than parsing `detail`. `detail` is unchanged. This is an open set: new values are added over time and a value is never repurposed, so treat an unrecognized `reason` as absent. Which operations return it today: - `createAccount` (onramp, offramp and swap) and `createTransaction` (a one-off transaction creates an account): every value in the table except `immutable_field`; `signature_required` comes from `createTransaction` only. - `updateAccount`: `field_invalid` (a developer fee that is out of range), `resource_not_found`, and `immutable_field` (the change would alter the account's routing; create a new account instead). - `deleteAccount`: `resource_not_found`. - `createInstructions`: a payment-agent instruction that creates an account fails with the same `reason` values as `createAccount`, but `params.field` is never returned there: the response carries the other `params` keys only, because this operation has no public field names to map to. - Other operations may also set `reason`. Treat a `reason` you do not recognize as absent, as above, and never assume an operation that is not listed here omits it. | `reason` | Meaning | `params` | | --- | --- | --- | | `field_required` | A required request field is missing. | `field` | | `field_invalid` | A field is present but unusable. | `field`, `constraint`, `rail` | | `field_too_long` | A field is longer than the rail allows. | `field`, `max`, `actual`, `rail` | | `field_too_short` | A field is shorter than the rail allows. | `field`, `min`, `actual` | | `address_incomplete` | An address lacks parts the route needs. | `subject`, `fields` | | `unsupported_network` | The network is not supported. | `network` | | `unsupported_asset` | The asset does not exist on the network. | `asset`, `network` | | `no_route_available` | No payment route covers the request. | `direction`, `rail`, `currency`, `network` | | `onboarding_required` | The customer has not completed onboarding for a capability. | `capability` | | `entity_not_active` | Onboarding for a capability exists but is not yet usable. | `capability`, `status` | | `destination_unreachable` | The destination cannot be reached over the requested rail. | `rail`, `alternative`, `direction` | | `limit_exceeded` | An amount exceeds a ceiling. | `limit`, `max`, `configured`, `currency` | | `resource_not_found` | The named resource does not exist. | `resource` | | `duplicate_resource` | A matching resource already exists. | `resource` | | `request_rejected` | The request was refused and the reason is not disclosed. | none | | `signature_required` | The request must be signed. | none | | `immutable_field` | The field cannot be changed on an existing account; create a new one. | none | example: field_too_long params: type: object description: | Parameters of `reason`. Every value is a string: a number, a token from a closed set, or the public name of a request field (`field` is expressed in this operation's request body, and is omitted when the offending value has no public name). Never free text. Present only alongside `reason`, and only when the reason has parameters. additionalProperties: type: string example: field: payment_reference max: '35' actual: '40' rail: swift TransactionType: type: string title: Transaction Type description: Type of transaction. enum: - onramp - offramp - swap example: onramp TransactionStatus: type: string title: Transaction Status description: Current status of a transaction. enum: - timed_out - not_started - in_progress - awaiting_confirmation - pending - processing - completed - invalid - failed - canceled - reversed - rejected - broadcasted - pending_return - returned - pending_reversal TransactionFailureCode: type: string description: > Stable, machine-readable reason a transaction failed, was returned, or was reversed. Pair it with the human-readable `failure_reason`, `return_reason` or `reversal_reason`, which carry Dakota's message for this code. Switch on `failure_code`, not on the message text, which may be reworded. `failure_code` is not a status: read `status` for the outcome. A returned payout keeps its code on `returned` and on the later `reversed` (the refund to the source wallet); payouts returned before this behaviour shipped may carry none. `payment_returned` is the code for a return whose bank reason does not map to a more specific value, including a return that carried no bank code at all. A payout that completes after a return (for example a resent wire) or after a rejected ACH reversal has no `failure_code`. The set of values is open: Dakota may add codes without a new API version, so treat any value you do not recognize like `processing_error`. `processing_error` is the general code for anything not listed; contact support with the transaction ID. enum: - recipient_account_not_found - recipient_account_number_invalid - recipient_account_blocked - recipient_account_type_unsupported - recipient_refused - recipient_name_mismatch - recipient_details_missing - recipient_address_invalid - recipient_bank_routing_invalid - recipient_bank_bic_invalid - limit_exceeded - payment_reversed_duplicate - payment_reversed_wrong_recipient - payment_reversed_wrong_amount - payment_returned - processing_error example: recipient_account_not_found TransactionReceipt: type: object description: Detailed receipt information for a transaction required: - input - output - exchange_rate properties: fx_outgoing_amounts: type: object additionalProperties: true description: >- Version 1 foreign outgoing amount_state unknown, with exact known source amount/currency and destination currency. Not a quote. fx_settlement: type: object additionalProperties: true description: >- Version 1 verified outgoing native settlement amounts and bank payout evidence. Absent means unknown, even when status is completed. imad: type: string description: Input Message Accountability Data for certain US transactions. omad: type: string description: Input Message Accountability Data for certain US transactions. uetr: type: string description: >- Unique End-to-end Transaction Reference (UETR), the RFC 4122 UUID that identifies this payment end to end across every institution on the wire rail. Absent for non-wire rails and for wires whose reference has not yet been assigned. input: $ref: '#/components/schemas/AmountDetails' description: Input amount details subtotal: $ref: '#/components/schemas/AmountDetails' description: Subtotal amount after fees converted: $ref: '#/components/schemas/AmountDetails' description: Converted amount after applying the exchange rate output: $ref: '#/components/schemas/AmountDetails' description: Output amount details exchange_rate: type: string description: Exchange rate used for the transaction external_fee: $ref: '#/components/schemas/AmountDetails' description: >- Fees charged by parties outside Dakota, such as banking partners. Currently reported as zero for bank transfers. For international (SWIFT) wires, intermediary and beneficiary banks can deduct fees en route; Dakota does not control or learn those deductions, and they do not appear here — the amount received can be lower than the amount sent. dakota_fee: $ref: '#/components/schemas/AmountDetails' description: Dakota fee amount details client_fee: type: object x-go-type: AmountDetails required: - amount - asset properties: amount: type: string description: Amount as a string representation of a decimal number asset: type: string description: Asset code network: type: string description: Network identifier for the token if it is a crypto asset deprecated: true x-deprecated-reason: Use developer_fee, which carries the same value. description: >- Deprecated: use `developer_fee`. Same value; will be removed in the next major version. developer_fee: $ref: '#/components/schemas/AmountDetails' description: >- Developer fee charged on this transaction. Always equal to the deprecated `client_fee`. developer_fee_bps: type: integer format: int32 description: >- Developer fee rate recorded on this transaction when it was created, in basis points (1 bp = 0.01%): for a deposit to an account, the account's rate at that time; for a one-off, the rate set on the request. It does not change afterwards, even if the account's rate does. `developer_fee` is the amount actually charged. 0 when the transaction carries a fixed fee (see `developer_fee_fixed`) or no developer fee. Absent when the rate is not known, for example on transactions created before this field was added. example: 50 developer_fee_fixed: type: string description: >- Fixed developer fee recorded on this transaction when it was created, in units of the asset deposited: for a deposit to an account, the account's fixed fee at that time; for a one-off, the fee set on the request. It does not change afterwards, even if the account's fee does. `developer_fee` is the amount actually charged, which can be lower. Absent when the transaction carries no fixed fee or the rate is not known. example: '10.00' gas_fee: $ref: '#/components/schemas/AmountDetails' description: Gas fee amount details for blockchain transactions payment_reference: type: string description: Payment reference message for bank transfers nullable: true example: Invoice payment for services TransactionCryptoDetails: type: object description: Blockchain-specific details for crypto transactions properties: source_crypto_address: type: string description: Source blockchain address source_network_id: $ref: '#/components/schemas/NetworkId' destination_crypto_address: type: string description: Destination blockchain address destination_network_id: $ref: '#/components/schemas/NetworkId' deposit_transaction_hash: type: string description: >- Transaction hash for intermediate transaction, such as the first half of an offramp or two-part swap transaction_hash: type: string description: >- Transaction hash for main transaction that reaches the recipient, if applicable SenderDetails: type: object description: >- Originating sender details for onramp/offramp/swap transactions. Populated when source-side metadata is available (e.g., from inbound wire/ACH source data). properties: sender_type: type: string description: >- Type of the originating sender (e.g., "fiat_account", "crypto_wallet"). example: fiat_account sender_account_holder_name: type: string description: Name on the originating account. example: John Doe sender_bank_name: type: string description: Bank name of the originating account. example: Chase Bank sender_routing_number: type: string description: ACH routing number of the originating bank account. example: '021000021' sender_account_number: type: string description: Account number of the originating bank account. example: '1234567890' sender_wire_routing_number: type: string description: Wire routing number of the originating bank account. example: '021000021' sender_account_type: type: string description: Type of the originating bank account (e.g., "checking", "savings"). example: checking sender_iban: type: string description: IBAN of the originating account. example: GB82WEST12345698765432 sender_bic: type: string description: BIC/SWIFT code of the originating bank. example: BARCGB22XXX sender_wallet_address: type: string description: Blockchain wallet address of the originating sender (offramp/swap). example: '0x1234567890abcdef1234567890abcdef12345678' sender_network: type: string description: >- Network identifier of the originating wallet (e.g., "ethereum-mainnet"). example: ethereum-mainnet ValidationError: type: object required: - field - message properties: field: type: string description: Field path using dot notation for nested fields. example: bank_account.routing_number message: type: string description: Human-readable description of the field error. example: Routing number must be exactly 9 digits code: type: string description: Machine-readable error code for this field. example: invalid_format AmountDetails: type: object description: >- Detailed representation of an amount with its asset and optional metadata required: - amount - asset properties: amount: type: string description: Amount as a string representation of a decimal number asset: type: string description: Asset code network: type: string description: Network identifier for the token if it is a crypto asset NetworkId: type: string description: Identifier for a blockchain network example: ethereum-mainnet enum: - ethereum-mainnet - ethereum-sepolia - ethereum-goerli - ethereum-holesky - solana-mainnet - solana-devnet - solana-testnet - base-mainnet - base-sepolia - arbitrum-mainnet - arbitrum-sepolia - optimism-mainnet - optimism-sepolia - polygon-mainnet - polygon-amoy minLength: 1 maxLength: 30 securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.