docs: describe rule-based accounts in sandbox - #889
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript Edit this comment to update them. They will appear in their respective SDK's changelogs. ⏳ grid-typescript studio⏳ grid-openapi studio⏳ grid-ruby studio⏳ grid-kotlin studio⏳ grid-go studio⏳ grid-python studio⏳ grid-php studio⏳ grid-cli studio⏳ These are partial results; builds are still running. This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
c227351 to
c324de7
Compare
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 below the corridor minimum rehearses the BELOW_MINIMUM path that returns the deposit and fires SWEEP.FAILED -- the behaviour most worth exercising before going live. The quote, bounds, destination checks and webhook are real; the settlement legs behind them are not.
82e6e81 to
0c1fe9f
Compare
c324de7 to
97881e2
Compare

Summary
Documents rule-based accounts in sandbox. Stacked on #835, which adds the endpoint and the sweep schemas.
No new paths, and no schema changes. Sandbox reuses the same surface: creation goes through
POST /internal-accounts, andPOST /sandbox/internal-accounts/{accountId}/fundalready exists to stand in for a settled deposit. What was missing is a statement of which half of the flow is real, so an integrator knows what a green sandbox run has actually proved.What changed
Two description blocks, +18 lines total:
POST /internal-accounts— notes that sandbox platforms can create rule-based accounts, that the account number is generated locally rather than issued by a partner bank, and that funding via the sandbox endpoint stands in for a deposit.POST /sandbox/internal-accounts/{accountId}/fund— a "Funding a rule-based account" section: funding triggers the sweep exactly as a settled deposit does, and funding below the corridor minimum rehearses theBELOW_MINIMUMpath that returns the deposit and deliversSWEEP.FAILED.That second one is the point of the change. Below-minimum is the behaviour an integrator is most likely to hit without meaning to, and the one whose consequence — the deposit going back to the payer rather than onward — is least guessable from the happy path.
Edited at source, not in the bundle
openapi.yamlandmintlify/openapi.yamlare bundler output —make buildregenerates them from theopenapi/directory. The two description blocks therefore live in their source files:openapi/paths/sandbox/sandbox_internal_accounts_{accountId}_fund.yamlopenapi/paths/internal_accounts.yamlwith both bundles rebuilt. An earlier revision of this PR edited the bundle directly, which would have been silently reverted by the next
make build— worth knowing if you review the diff and wonder why three files carry the same prose.The boundary this draws
This is a deliberate boundary rather than a shortfall. The alternative — registering real partner-bank entities for fictional sandbox customers — is precisely what the platform eligibility rules exist to prevent. Everything above the rails genuinely runs: the same rule lookup, balance read, corridor bounds, destination and rail validation, quote path and webhook that production uses.