> ## 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 simulation status

> Returns the current state and callback delivery history for a sandbox simulation.
Use this to debug async flows — see whether callbacks have been scheduled, delivered,
or failed. Available in sandbox mode only.




## OpenAPI

````yaml /openapi.yaml get /sandbox/simulations/{simulation_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-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:
  /sandbox/simulations/{simulation_id}:
    get:
      tags:
        - Sandbox
      summary: Get simulation status
      description: >
        Returns the current state and callback delivery history for a sandbox
        simulation.

        Use this to debug async flows — see whether callbacks have been
        scheduled, delivered,

        or failed. Available in sandbox mode only.
      operationId: getSimulation
      parameters:
        - name: simulation_id
          in: path
          required: true
          schema:
            type: string
          description: The simulation_id returned by POST /sandbox/simulate/inbound
      responses:
        '200':
          description: Simulation found
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/SimulationInspection'
              example:
                simulation_id: sim_qa_run_001
                rail: ach
                operation: inbound_posted
                scenario: success_immediate
                state: settled
                organization_id: org_01HXYZ
                account_id: acc_123
                amount: '100.00'
                currency: USD
                created_at: '2024-01-15T10:30:00Z'
                completed_at: '2024-01-15T10:30:05Z'
                callbacks:
                  - callback_id: cb_001
                    state: delivered
                    attempts: 1
                    max_attempts: 3
                    scheduled_for: '2024-01-15T10:30:01Z'
                    delivered_at: '2024-01-15T10:30:02Z'
        '403':
          description: Not available in production
          content:
            application/problem+json:
              schema:
                $ref: '#/components/schemas/ProblemDetails'
              example:
                type: https://docs.dakota.xyz/api-reference/errors#forbidden
                title: Not available in production
                status: 403
                detail: Not available in production
                instance: https://api.platform.dakota.xyz/sandbox/simulations/example-id
                request_id: req_01hzy6y7v8w9x0y1z2a3b4c5d6
        '404':
          description: Simulation not found
          content:
            application/problem+json:
              schema:
                $ref: '#/components/schemas/ProblemDetails'
              example:
                type: https://docs.dakota.xyz/api-reference/errors#not-found
                title: Simulation not found
                status: 404
                detail: Simulation not found
                instance: https://api.platform.dakota.xyz/sandbox/simulations/example-id
                request_id: req_01hzy6y7v8w9x0y1z2a3b4c5d6
        '502':
          description: Provider gRPC error
          content:
            application/problem+json:
              schema:
                $ref: '#/components/schemas/ProblemDetails'
              example:
                type: https://docs.dakota.xyz/api-reference/errors#provider-error
                title: Provider gRPC error
                status: 502
                detail: Provider gRPC error
                instance: https://api.platform.dakota.xyz/sandbox/simulations/example-id
                request_id: req_01hzy6y7v8w9x0y1z2a3b4c5d6
      externalDocs:
        description: Read full guide in docs
        url: https://docs.dakota.xyz/api-reference/sandbox/get-simulation-status
components:
  schemas:
    SimulationInspection:
      type: object
      description: Full simulation state including callback history.
      required:
        - simulation_id
        - rail
        - operation
        - scenario
        - state
        - organization_id
        - amount
        - currency
        - created_at
      properties:
        simulation_id:
          type: string
          description: Simulation identifier
        rail:
          type: string
          description: Payment rail (ach, wire, crypto)
        operation:
          type: string
          description: Operation type (inbound_posted, outbound_failed, etc.)
        scenario:
          type: string
          description: >-
            Scenario name (success_immediate, success_delayed, compliance_hold,
            etc.)
        state:
          type: string
          description: >-
            Current simulation state (accepted, settled, returned, rejected,
            failed)
        state_position:
          type: string
          description: Sub-state for multi-step scenarios (e.g. post_hold)
        awaiting_advance:
          type: boolean
          description: Whether the simulation is paused waiting for a POST /advance call
        organization_id:
          type: string
          description: Organization that owns this simulation
        account_id:
          type: string
          description: Platform account ID (for fiat simulations)
        wallet_id:
          type: string
          description: Platform wallet ID (for crypto simulations)
        amount:
          type: string
          description: Amount as decimal string (e.g. "100.50")
        currency:
          type: string
          description: ISO 4217 currency code
        trace_id:
          type: string
          description: Caller-supplied trace ID
        metadata:
          type: object
          additionalProperties:
            type: string
          description: Caller-supplied metadata (informational only)
        created_at:
          type: string
          format: date-time
          description: When the simulation was created
        completed_at:
          type: string
          format: date-time
          description: >-
            When the simulation reached a terminal state (omitted if still in
            progress)
        callbacks:
          type: array
          items:
            $ref: '#/components/schemas/SimulationCallbackRecord'
          description: Callback delivery log ordered by scheduled_for ascending
        advance_actions_available:
          type: array
          items:
            type: string
          description: >-
            Valid advance actions when awaiting_advance is true (e.g.
            ["release", "reject"])
    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'
    SimulationCallbackRecord:
      type: object
      description: One callback delivery log entry for a simulation.
      properties:
        callback_id:
          type: string
          description: Opaque callback identifier (UUID)
        payload_json:
          type: string
          description: Full webhook payload (JSON-encoded string)
        scheduled_for:
          type: string
          format: date-time
          description: When the callback is scheduled to fire
        state:
          type: string
          enum:
            - pending
            - delivered
            - failed
          description: Delivery state of this callback
        attempts:
          type: integer
          description: Number of delivery attempts made
        max_attempts:
          type: integer
          description: Maximum allowed delivery attempts
        delivered_at:
          type: string
          format: date-time
          description: >-
            When the callback was successfully delivered (omitted if not yet
            delivered)
        last_error:
          type: string
          description: Last error message if delivery failed
    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

````