> ## 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. # Schedule a payment directly (ALPHA) > > **Alpha** — early access. Creates one or more scheduled payments for a signer WITHOUT the proposal flow — schedule directly under an existing active mandate (coverage is matched at fire time, so no new signature is needed here). The payments bind the given signer and funding wallet. The signer must be permitted to spend on that wallet, the wallet must belong to the calling client, and the destination must be a crypto destination of the wallet's customer. The schedule is explicit `dates` (one payment per timestamp) OR `count` × `interval_seconds` from `start_at` (0 ⇒ now); dates are unix SECONDS and are rejected if in the past or implausibly far ahead. Whether a mandate covers each payment is decided at fire time by the money-path gate — a scheduled payment with no covering active mandate fails at fire, it is not rejected here. ## OpenAPI ````yaml /openapi.yaml post /scheduled-payments 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-alpha: true description: >- Alpha — 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-alpha: true description: >- Alpha — 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-alpha: true description: >- Alpha — read-only account insight: a deterministic report over a customer's agentic activity (funding balances, upcoming obligations, failures, mandate headroom and expiry) plus an advisory chat that narrates it. 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: 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: 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. **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 paths: /scheduled-payments: post: tags: - Agentic Payments summary: Schedule a payment directly (ALPHA) description: > > **Alpha** — early access. Creates one or more scheduled payments for a signer WITHOUT the proposal flow — schedule directly under an existing active mandate (coverage is matched at fire time, so no new signature is needed here). The payments bind the given signer and funding wallet. The signer must be permitted to spend on that wallet, the wallet must belong to the calling client, and the destination must be a crypto destination of the wallet's customer. The schedule is explicit `dates` (one payment per timestamp) OR `count` × `interval_seconds` from `start_at` (0 ⇒ now); dates are unix SECONDS and are rejected if in the past or implausibly far ahead. Whether a mandate covers each payment is decided at fire time by the money-path gate — a scheduled payment with no covering active mandate fails at fire, it is not rejected here. operationId: createScheduledPayment parameters: - $ref: '#/components/parameters/IdempotencyKeyHeader' requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/CreateScheduledPaymentRequest' example: signer_id: 2vWxSigner000000000000000000 wallet_id: 2vWxWallet000000000000000000 destination_id: 2vWxDestination00000000000000 amount: '10000' asset: USDC dates: - 1781481600 responses: '201': description: The scheduled payments that were created (one row per date) content: application/json: schema: type: array items: $ref: '#/components/schemas/ScheduledPaymentResponse' example: - id: 2vWxScheduled000000000000000 signer_id: 2vWxSigner000000000000000000 wallet_id: 2vWxWallet000000000000000000 amount: '10000' asset: USDC address: '0xa11ce00000000000000000000000000000000001' network_id: base-sepolia status: scheduled scheduled_at: 1781481600 '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: signer is not permitted to spend on wallet '404': description: Agentic payments not enabled, or the resource was 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: wallet not found components: parameters: IdempotencyKeyHeader: name: x-idempotency-key in: header required: true description: >- Unique key to ensure request idempotency. If the same key is used within a certain time window, the original response will be returned instead of executing the request again. schema: type: string format: uuid schemas: CreateScheduledPaymentRequest: type: object required: - signer_id - wallet_id - amount - asset description: > Direct (signer-first) schedule create. The signer + funding wallet are the caller's choice; the schedule is explicit `dates`, or `count` × `interval_seconds` from `start_at`. Name the payee EITHER with `destination_id` (an existing crypto destination of the wallet's customer) OR with a direct `address` + `network_id` (a raw crypto address, no recipient — matched on the address at fire time, like a mandate address target) — exactly one of the two. properties: signer_id: type: string description: >- The signer the payments bind to; its hosted agent signs at fire time. wallet_id: type: string description: > The funding wallet these payments spend from. Required — the signer must be permitted to spend on it, and its chain family must match the payment network. destination_id: type: string description: >- An existing crypto destination of the wallet's customer to pay. Omit to pay a direct address (address + network_id). address: type: string description: >- A direct crypto address to pay — an alternative to destination_id (no recipient). Requires network_id; the wallet's chain family must match. network_id: type: string description: >- The network for a direct-address payment (required together with address). amount: type: string description: Decimal string, at the destination asset. asset: type: string dates: type: array maxItems: 366 items: type: integer format: int64 description: >- Explicit per-payment unix times (one payment each). Win over count × interval_seconds. count: type: integer maximum: 366 description: Number of payments when using count × interval_seconds (default 1). interval_seconds: type: integer format: int64 description: Cadence in seconds between payments when using count. start_at: type: integer format: int64 description: First due time (0 ⇒ now). ScheduledPaymentResponse: type: object properties: id: type: string signer_id: type: string description: >- The signer (hosted agent) this payment fires under. Updatable via PATCH while scheduled. wallet_id: type: string description: >- The funding wallet this payment spends from (the customer's choice at acceptance; updatable via PATCH while scheduled). mandate_id: type: string description: >- AUDIT — the mandate that covered this payment at fire time. Absent until the payment executes (coverage is decided at fire time, not bound at rest). wallet_transaction_id: type: string description: >- AUDIT — the money-path transaction created when this payment fired. Absent until the payment executes. amount: type: string asset: type: string failure_reason: type: string description: >- Why the payment failed (e.g. the mandate gate's denied dimensions); absent unless status is failed. recipient_id: type: string description: >- The recipient this payment pays, when it was created from a destination. Absent for a direct-address payment (which carries no recipient). destination_id: type: string description: >- The REAL destination this payment settles to — a bank (for an offramp) or a crypto destination. For an auto-account (convert-and-forward) payment, `address` is the crypto DEPOSIT actually paid while this names the bank/crypto target, so a client can show which account the scheduled payment is for. Absent for a direct-address payment. destination_type: type: string enum: - bank - crypto description: >- The kind of the REAL destination (see destination_id). `bank` marks an offramp (the payment converts crypto to fiat and forwards via a bank rail); `crypto` a direct or cross-family crypto payout. Absent for a direct-address payment with no destination. destination_label: type: string description: >- A human label for the real destination — e.g. "Chase ••••5432" for a bank, or a shortened address for crypto — so a client can show which account the payment settles to without a second lookup. Absent when unresolved. destination_rail: type: string description: >- For a `bank` destination, the payout rail (e.g. ach, fedwire, swift). Absent for crypto. output_asset: type: string description: >- The asset the recipient ULTIMATELY receives. For an offramp this is the fiat currency (e.g. USD) the deposit converts to; for a direct crypto payment it equals `asset`. Stablecoin conversion is 1:1, so the output AMOUNT equals `amount`. output_network: type: string description: >- For a crypto destination, the network the recipient ULTIMATELY receives on — for a cross-family swap this differs from `network_id` (the DEPOSIT network the wallet pays), e.g. output_network solana-devnet while network_id is base-sepolia. Equals `network_id` for a direct crypto payment; absent for a bank offramp (fiat has no network). address: type: string network_id: type: string status: type: string enum: - scheduled - cancelled - executed - failed executed_at: type: integer format: int64 scheduled_at: type: integer format: int64 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' 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 securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key ````