> ## Documentation Index
> Fetch the complete documentation index at: https://docs.daya.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Create a sandbox deposit

> Trigger a mock deposit in sandbox to test the full deposit → settlement/webhook flow

## Overview

This sandbox-only endpoint creates a mock deposit for an existing funding account.

By default, Daya runs the simulated deposit through the same processing pipeline as a real deposit:

* Deposit creation
* Settlement to internal balance, onchain payout, or NGN payout
* Webhook dispatch

You can also pass `scenario` to trigger a specific sandbox lifecycle outcome. Use scenarios when you need to confirm your app handles specific deposit states without waiting for the sandbox processor to produce them naturally.

Use this to validate deposit processing and webhook handling before going to production. Create the receive instruction with `/v1/funding-accounts`, then pass the returned funding account `id` to this endpoint.

<Warning>
  This endpoint is **not available in production**. Calls in production return `403 Not available in production`.
</Warning>

<Tip>
  For end-to-end guidance (recommended flow, what to validate, and common flagging scenarios), see [Sandbox testing](/limits/sandbox-testing).
</Tip>

## Authentication

<ParamField header="X-Api-Key" type="string" required>
  Your merchant API key
</ParamField>

## Request Body

<ParamField body="funding_account_id" type="string" required>
  Funding account ID to simulate a deposit for. Daya uses the funding account to decide whether the simulated deposit is NGN or crypto, and where settlement should go.

  **Example:** `6b0e8400-e29b-41d4-a716-446655440000`
</ParamField>

<ParamField body="scenario" type="string">
  Optional sandbox lifecycle outcome to trigger.

  Allowed values:

  * `PROCESSING`
  * `COMPLETED`
  * `REQUIRES_REVIEW`
  * `FAILED`

  Omit this field to use the default sandbox processing flow.
</ParamField>

## Request Examples

<CodeGroup>
  ```bash Default flow theme={null}
  curl --request POST \
    --url https://api.sandbox.daya.co/v1/sandbox/deposits \
    --header 'X-Api-Key: YOUR_SANDBOX_KEY' \
    --header 'Content-Type: application/json' \
    --data '{
      "funding_account_id": "6b0e8400-e29b-41d4-a716-446655440000"
    }'
  ```

  ```bash Trigger completed theme={null}
  curl --request POST \
    --url https://api.sandbox.daya.co/v1/sandbox/deposits \
    --header 'X-Api-Key: YOUR_SANDBOX_KEY' \
    --header 'Content-Type: application/json' \
    --data '{
      "funding_account_id": "6b0e8400-e29b-41d4-a716-446655440000",
      "scenario": "COMPLETED"
    }'
  ```

  ```bash Trigger review theme={null}
  curl --request POST \
    --url https://api.sandbox.daya.co/v1/sandbox/deposits \
    --header 'X-Api-Key: YOUR_SANDBOX_KEY' \
    --header 'Content-Type: application/json' \
    --data '{
      "funding_account_id": "6b0e8400-e29b-41d4-a716-446655440000",
      "scenario": "REQUIRES_REVIEW"
    }'
  ```
</CodeGroup>

## Response

Returns a confirmation message and the simulated deposit status. Use `/v1/deposits` and webhook events to track the simulated deposit.

* `message`: Human-readable status message
* `deposit_id`: Created deposit ID
* `status`: Current deposit status
* `scenario`: Scenario that was applied, if provided

```json theme={null}
{
  "message": "Sandbox deposit created for processing.",
  "deposit_id": "4b4a0f1f-f1dc-4f4c-a77d-3f4ebc8b4f42",
  "status": "COMPLETED",
  "scenario": "COMPLETED"
}
```

## Testing lifecycle outcomes

Use `scenario` to test the state machine in your integration:

| Scenario          | Expected webhook path                          | Use this to test                      |
| ----------------- | ---------------------------------------------- | ------------------------------------- |
| `PROCESSING`      | `deposit.received` → `deposit.processing`      | In-progress UI and retry-safe polling |
| `COMPLETED`       | `deposit.received` → `deposit.completed`       | Crediting/final success logic         |
| `REQUIRES_REVIEW` | `deposit.received` → `deposit.requires_review` | Review/hold states                    |
| `FAILED`          | `deposit.received` → `deposit.failed`          | Failure messaging and recovery        |

<Note>
  Scenario outcomes are for testing a specific lifecycle state in sandbox. `PROCESSING` and `COMPLETED` still use the funding account's active settlement destination, so the funding account must include any required `rate_id`, destination wallet, or destination bank details. To test the production-like settlement processor and any natural intermediate states, omit `scenario`.
</Note>

## Error Responses

This endpoint may return:

* `400`: Invalid request
* `401`: Unauthorized
* `403`: Not available in production
* `404`: Funding account not found
* `500`: Internal server error

## Next Steps

<CardGroup cols={2}>
  <Card title="Webhooks Overview" icon="bell" href="/api-reference/webhooks/overview">
    Verify your webhook handling with sandbox events
  </Card>

  <Card title="Sandbox testing" icon="flask" href="/limits/sandbox-testing">
    Recommended end-to-end sandbox flow + common flagging scenarios
  </Card>
</CardGroup>