From 44ba009a3c05e413cdfd72131886d1de6139177e Mon Sep 17 00:00:00 2001 From: Brian Date: Wed, 2 Sep 2026 00:10:25 +0000 Subject: [PATCH 1/5] docs: describe rule-based accounts in sandbox Sandbox needs no new paths: creation reuses POST /internal-accounts and a settled deposit is stood in for by the existing sandbox fund endpoint. What it does need is saying which half is real, so an integrator knows what a green sandbox run has actually proved. Funding a rule-based account triggers its sweep, and funding outside the corridor band rehearses the path that moves the balance to the customer's canonical account and fires SWEEP.FAILED -- the behaviour most worth exercising before going live, since the rule-based account is left at zero either way. The quote, bounds, destination checks and webhook are real; the settlement legs behind them are not. --- mintlify/openapi.yaml | 3 +++ openapi.yaml | 3 +++ ...box_internal_accounts_{accountId}_fund.yaml | 18 ++++++++++++++++++ 3 files changed, 24 insertions(+) diff --git a/mintlify/openapi.yaml b/mintlify/openapi.yaml index 43321c8af..ff200e0a7 100644 --- a/mintlify/openapi.yaml +++ b/mintlify/openapi.yaml @@ -5574,6 +5574,9 @@ paths: description: | Simulate receiving funds into an internal account in the sandbox environment. This is useful for testing scenarios where you need to add funds to a customer's or platform's internal account without going through a real bank transfer or following payment instructions. This endpoint is only for the sandbox environment and will fail for production platforms/keys. + ### Funding a rule-based account + Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is forwarded to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the customer's canonical account in the same currency instead, and `SWEEP.FAILED` is delivered with `outcome: MOVED_TO_CANONICAL_ACCOUNT` and either `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. + Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and the webhook are all real; the settlement legs behind them are not, so timings and failure modes that originate at a partner bank cannot be reproduced here. operationId: sandboxFundInternalAccount tags: - Sandbox diff --git a/openapi.yaml b/openapi.yaml index 43321c8af..ff200e0a7 100644 --- a/openapi.yaml +++ b/openapi.yaml @@ -5574,6 +5574,9 @@ paths: description: | Simulate receiving funds into an internal account in the sandbox environment. This is useful for testing scenarios where you need to add funds to a customer's or platform's internal account without going through a real bank transfer or following payment instructions. This endpoint is only for the sandbox environment and will fail for production platforms/keys. + ### Funding a rule-based account + Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is forwarded to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the customer's canonical account in the same currency instead, and `SWEEP.FAILED` is delivered with `outcome: MOVED_TO_CANONICAL_ACCOUNT` and either `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. + Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and the webhook are all real; the settlement legs behind them are not, so timings and failure modes that originate at a partner bank cannot be reproduced here. operationId: sandboxFundInternalAccount tags: - Sandbox diff --git a/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml b/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml index a25767b17..8a5667157 100644 --- a/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml +++ b/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml @@ -8,6 +8,24 @@ post: This endpoint is only for the sandbox environment and will fail for production platforms/keys. + + ### Funding a rule-based account + + Funding a `RULE_BASED` account triggers its sweep, exactly as a settled + deposit does in production: the balance is forwarded to the rule's + destination and the account is left at zero. A balance outside the corridor + band moves to the customer's canonical account in the same currency + instead, and `SWEEP.FAILED` is delivered with + `outcome: MOVED_TO_CANONICAL_ACCOUNT` and either + `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a rule-based + account with a very small amount to rehearse that path. Either way the + rule-based account is left at zero; it never holds a balance. + + Sandbox simulates the API contract and the routing decision, not the + banking rails. The quote, the corridor bounds, the destination checks and + the webhook are all real; the settlement legs behind them are not, so + timings and failure modes that originate at a partner bank cannot be + reproduced here. operationId: sandboxFundInternalAccount tags: - Sandbox From d26a71726172ac301baed32e73934003e69ba0e8 Mon Sep 17 00:00:00 2001 From: Brian Date: Wed, 2 Sep 2026 20:27:14 +0000 Subject: [PATCH 2/5] sandbox: match the sweep wording and the outcome removal --- mintlify/openapi.yaml | 2 +- openapi.yaml | 2 +- .../sandbox_internal_accounts_{accountId}_fund.yaml | 11 +++++------ 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/mintlify/openapi.yaml b/mintlify/openapi.yaml index ff200e0a7..64e2e33c3 100644 --- a/mintlify/openapi.yaml +++ b/mintlify/openapi.yaml @@ -5575,7 +5575,7 @@ paths: Simulate receiving funds into an internal account in the sandbox environment. This is useful for testing scenarios where you need to add funds to a customer's or platform's internal account without going through a real bank transfer or following payment instructions. This endpoint is only for the sandbox environment and will fail for production platforms/keys. ### Funding a rule-based account - Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is forwarded to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the customer's canonical account in the same currency instead, and `SWEEP.FAILED` is delivered with `outcome: MOVED_TO_CANONICAL_ACCOUNT` and either `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. + Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the customer's canonical account in the same currency instead, and `SWEEP.FAILED` is delivered carrying `canonicalAccountId` and either `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and the webhook are all real; the settlement legs behind them are not, so timings and failure modes that originate at a partner bank cannot be reproduced here. operationId: sandboxFundInternalAccount tags: diff --git a/openapi.yaml b/openapi.yaml index ff200e0a7..64e2e33c3 100644 --- a/openapi.yaml +++ b/openapi.yaml @@ -5575,7 +5575,7 @@ paths: Simulate receiving funds into an internal account in the sandbox environment. This is useful for testing scenarios where you need to add funds to a customer's or platform's internal account without going through a real bank transfer or following payment instructions. This endpoint is only for the sandbox environment and will fail for production platforms/keys. ### Funding a rule-based account - Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is forwarded to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the customer's canonical account in the same currency instead, and `SWEEP.FAILED` is delivered with `outcome: MOVED_TO_CANONICAL_ACCOUNT` and either `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. + Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the customer's canonical account in the same currency instead, and `SWEEP.FAILED` is delivered carrying `canonicalAccountId` and either `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and the webhook are all real; the settlement legs behind them are not, so timings and failure modes that originate at a partner bank cannot be reproduced here. operationId: sandboxFundInternalAccount tags: diff --git a/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml b/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml index 8a5667157..9d1670d62 100644 --- a/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml +++ b/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml @@ -12,14 +12,13 @@ post: ### Funding a rule-based account Funding a `RULE_BASED` account triggers its sweep, exactly as a settled - deposit does in production: the balance is forwarded to the rule's + deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the customer's canonical account in the same currency - instead, and `SWEEP.FAILED` is delivered with - `outcome: MOVED_TO_CANONICAL_ACCOUNT` and either - `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a rule-based - account with a very small amount to rehearse that path. Either way the - rule-based account is left at zero; it never holds a balance. + instead, and `SWEEP.FAILED` is delivered carrying `canonicalAccountId` and + either `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a + rule-based account with a very small amount to rehearse that path. Either + way the rule-based account is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and From 0ec4092b9212dddc99c812848933572a0f347074 Mon Sep 17 00:00:00 2001 From: Brian Date: Wed, 2 Sep 2026 23:46:32 +0000 Subject: [PATCH 3/5] sandbox: describe the sweep outcome on the transaction --- mintlify/openapi.yaml | 2 +- openapi.yaml | 2 +- .../sandbox_internal_accounts_{accountId}_fund.yaml | 10 +++++----- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/mintlify/openapi.yaml b/mintlify/openapi.yaml index 64e2e33c3..2c5adb435 100644 --- a/mintlify/openapi.yaml +++ b/mintlify/openapi.yaml @@ -5575,7 +5575,7 @@ paths: Simulate receiving funds into an internal account in the sandbox environment. This is useful for testing scenarios where you need to add funds to a customer's or platform's internal account without going through a real bank transfer or following payment instructions. This endpoint is only for the sandbox environment and will fail for production platforms/keys. ### Funding a rule-based account - Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the customer's canonical account in the same currency instead, and `SWEEP.FAILED` is delivered carrying `canonicalAccountId` and either `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. + Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency instead, and the transaction carries `sweepCanonicalAccountId` with either `sweepFailureReason: BELOW_MINIMUM` or `ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and the webhook are all real; the settlement legs behind them are not, so timings and failure modes that originate at a partner bank cannot be reproduced here. operationId: sandboxFundInternalAccount tags: diff --git a/openapi.yaml b/openapi.yaml index 64e2e33c3..2c5adb435 100644 --- a/openapi.yaml +++ b/openapi.yaml @@ -5575,7 +5575,7 @@ paths: Simulate receiving funds into an internal account in the sandbox environment. This is useful for testing scenarios where you need to add funds to a customer's or platform's internal account without going through a real bank transfer or following payment instructions. This endpoint is only for the sandbox environment and will fail for production platforms/keys. ### Funding a rule-based account - Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the customer's canonical account in the same currency instead, and `SWEEP.FAILED` is delivered carrying `canonicalAccountId` and either `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. + Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency instead, and the transaction carries `sweepCanonicalAccountId` with either `sweepFailureReason: BELOW_MINIMUM` or `ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and the webhook are all real; the settlement legs behind them are not, so timings and failure modes that originate at a partner bank cannot be reproduced here. operationId: sandboxFundInternalAccount tags: diff --git a/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml b/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml index 9d1670d62..421790e6b 100644 --- a/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml +++ b/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml @@ -14,11 +14,11 @@ post: Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor - band moves to the customer's canonical account in the same currency - instead, and `SWEEP.FAILED` is delivered carrying `canonicalAccountId` and - either `reason: BELOW_MINIMUM` or `reason: ABOVE_MAXIMUM` — fund a - rule-based account with a very small amount to rehearse that path. Either - way the rule-based account is left at zero; it never holds a balance. + band moves to the account holder's own account in the same currency + instead, and the transaction carries `sweepCanonicalAccountId` with either + `sweepFailureReason: BELOW_MINIMUM` or `ABOVE_MAXIMUM` — fund a rule-based + account with a very small amount to rehearse that path. Either way the + rule-based account is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and From eeba908bd97d328ace80ac9d58cfba1b891043b6 Mon Sep 17 00:00:00 2001 From: Brian Date: Thu, 3 Sep 2026 21:14:22 +0000 Subject: [PATCH 4/5] sandbox: describe the sweep failure on failureReason --- mintlify/openapi.yaml | 2 +- openapi.yaml | 2 +- .../sandbox_internal_accounts_{accountId}_fund.yaml | 8 ++++---- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/mintlify/openapi.yaml b/mintlify/openapi.yaml index 2c5adb435..e1e8fb74e 100644 --- a/mintlify/openapi.yaml +++ b/mintlify/openapi.yaml @@ -5575,7 +5575,7 @@ paths: Simulate receiving funds into an internal account in the sandbox environment. This is useful for testing scenarios where you need to add funds to a customer's or platform's internal account without going through a real bank transfer or following payment instructions. This endpoint is only for the sandbox environment and will fail for production platforms/keys. ### Funding a rule-based account - Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency instead, and the transaction carries `sweepCanonicalAccountId` with either `sweepFailureReason: BELOW_MINIMUM` or `ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. + Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency instead, and the transaction fails with either `failureReason: SWEEP_BELOW_MINIMUM` or `SWEEP_ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and the webhook are all real; the settlement legs behind them are not, so timings and failure modes that originate at a partner bank cannot be reproduced here. operationId: sandboxFundInternalAccount tags: diff --git a/openapi.yaml b/openapi.yaml index 2c5adb435..e1e8fb74e 100644 --- a/openapi.yaml +++ b/openapi.yaml @@ -5575,7 +5575,7 @@ paths: Simulate receiving funds into an internal account in the sandbox environment. This is useful for testing scenarios where you need to add funds to a customer's or platform's internal account without going through a real bank transfer or following payment instructions. This endpoint is only for the sandbox environment and will fail for production platforms/keys. ### Funding a rule-based account - Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency instead, and the transaction carries `sweepCanonicalAccountId` with either `sweepFailureReason: BELOW_MINIMUM` or `ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. + Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency instead, and the transaction fails with either `failureReason: SWEEP_BELOW_MINIMUM` or `SWEEP_ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and the webhook are all real; the settlement legs behind them are not, so timings and failure modes that originate at a partner bank cannot be reproduced here. operationId: sandboxFundInternalAccount tags: diff --git a/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml b/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml index 421790e6b..47118248f 100644 --- a/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml +++ b/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml @@ -15,10 +15,10 @@ post: deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency - instead, and the transaction carries `sweepCanonicalAccountId` with either - `sweepFailureReason: BELOW_MINIMUM` or `ABOVE_MAXIMUM` — fund a rule-based - account with a very small amount to rehearse that path. Either way the - rule-based account is left at zero; it never holds a balance. + instead, and the transaction fails with either + `failureReason: SWEEP_BELOW_MINIMUM` or `SWEEP_ABOVE_MAXIMUM` — fund a + rule-based account with a very small amount to rehearse that path. Either + way the rule-based account is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and From 3bc0826f0f7bd9d03249de11f51a5f17bfd20203 Mon Sep 17 00:00:00 2001 From: Brian Date: Thu, 3 Sep 2026 21:31:53 +0000 Subject: [PATCH 5/5] sandbox: use the collapsed sweep amount reason --- mintlify/openapi.yaml | 2 +- openapi.yaml | 2 +- .../sandbox_internal_accounts_{accountId}_fund.yaml | 8 ++++---- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/mintlify/openapi.yaml b/mintlify/openapi.yaml index e1e8fb74e..7944d6f18 100644 --- a/mintlify/openapi.yaml +++ b/mintlify/openapi.yaml @@ -5575,7 +5575,7 @@ paths: Simulate receiving funds into an internal account in the sandbox environment. This is useful for testing scenarios where you need to add funds to a customer's or platform's internal account without going through a real bank transfer or following payment instructions. This endpoint is only for the sandbox environment and will fail for production platforms/keys. ### Funding a rule-based account - Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency instead, and the transaction fails with either `failureReason: SWEEP_BELOW_MINIMUM` or `SWEEP_ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. + Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency instead, and the transaction fails with `failureReason: SWEEP_AMOUNT_OUT_OF_RANGE` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and the webhook are all real; the settlement legs behind them are not, so timings and failure modes that originate at a partner bank cannot be reproduced here. operationId: sandboxFundInternalAccount tags: diff --git a/openapi.yaml b/openapi.yaml index e1e8fb74e..7944d6f18 100644 --- a/openapi.yaml +++ b/openapi.yaml @@ -5575,7 +5575,7 @@ paths: Simulate receiving funds into an internal account in the sandbox environment. This is useful for testing scenarios where you need to add funds to a customer's or platform's internal account without going through a real bank transfer or following payment instructions. This endpoint is only for the sandbox environment and will fail for production platforms/keys. ### Funding a rule-based account - Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency instead, and the transaction fails with either `failureReason: SWEEP_BELOW_MINIMUM` or `SWEEP_ABOVE_MAXIMUM` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. + Funding a `RULE_BASED` account triggers its sweep, exactly as a settled deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency instead, and the transaction fails with `failureReason: SWEEP_AMOUNT_OUT_OF_RANGE` — fund a rule-based account with a very small amount to rehearse that path. Either way the rule-based account is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and the webhook are all real; the settlement legs behind them are not, so timings and failure modes that originate at a partner bank cannot be reproduced here. operationId: sandboxFundInternalAccount tags: diff --git a/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml b/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml index 47118248f..0cfc9b9a0 100644 --- a/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml +++ b/openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yaml @@ -15,10 +15,10 @@ post: deposit does in production: the balance is swept to the rule's destination and the account is left at zero. A balance outside the corridor band moves to the account holder's own account in the same currency - instead, and the transaction fails with either - `failureReason: SWEEP_BELOW_MINIMUM` or `SWEEP_ABOVE_MAXIMUM` — fund a - rule-based account with a very small amount to rehearse that path. Either - way the rule-based account is left at zero; it never holds a balance. + instead, and the transaction fails with + `failureReason: SWEEP_AMOUNT_OUT_OF_RANGE` — fund a rule-based account with + a very small amount to rehearse that path. Either way the rule-based account + is left at zero; it never holds a balance. Sandbox simulates the API contract and the routing decision, not the banking rails. The quote, the corridor bounds, the destination checks and