Conversation
Adds the two operations a platform needs to build and evidence a periodic
statement for an internal account: GET /internal-accounts/{id}/balance-changes
returns one row per change to the balance with the window's opening and closing
balances in the same response, and POST
/internal-accounts/{id}/statement-confirmations records that a statement was
delivered. Adds 409 BALANCE_NOT_YET_FINAL and 422 PERIOD_NOT_REPORTABLE.
Co-Authored-By: benwgold <benwgold@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Contributor
|
This PR does not match any of the 3 configured review trigger rules. |
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
benwgold
marked this pull request as ready for review
September 26, 2026 00:11
This stack of pull requests is managed by Graphite. Learn more about stacking. |
The code tells a caller to come back later, which is not specific to balances. A generic name lets any endpoint whose answer is not ready yet reuse it, and the reason text still says what is outstanding. Co-Authored-By: benwgold <benwgold@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
Every settled window can now be served, so balance changes no longer answers 422 PERIOD_NOT_REPORTABLE. Co-Authored-By: benwgold <benwgold@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…delivery can be confirmed A statement covers a customer's whole balance and is issued for their own USD account; rule-based, bulk settlement and platform-owned accounts are refused. A period is a calendar month in US Central time, and only a window that is exactly one such month counts as a statement fetch, so the examples now carry the Central offset. deliveredAt, and the request time it defaults to, must fall after the period ends. The balance-changes 400 also names an unrecognized cursor. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Summary
Adds the two operations a platform needs to build a Regulation E periodic statement for an internal account and record that it was delivered. Both sit under a new Periodic Statements tag.
GET /internal-accounts/{id}/balance-changesreturns one row per change to the account's balance in a half-open window[from, to), ordered by when the money moved. The window'sopeningBalanceandclosingBalancecome in the same response. The balances describe the window rather than the page, soopeningBalance + Σ(data[].amount) == closingBalanceholds summed across all pages. Paginated withlimit/cursor.POST /internal-accounts/{id}/statement-confirmationsrecords that a period's statement was delivered to the customer. It is idempotent, and the stored time is the first delivery.Contract details documented in the spec:
America/Chicago). The examples use Central offsets, and only a window of exactly one such month counts as a statement fetch.400.deliveredAt, or the request time it defaults to, must not be in the future and must be at or after the end of the period.transactionIdon a balance change groups the lines of one movement. The spec says it is not aTransactionid.New error code:
409 NOT_YET_AVAILABLE. The request is valid, but its result could still change, so it isn't served yet; retry later. The name is generic so other endpoints can reuse it. For balance changes it means card settlement for a window boundary has not closed.Changes
openapi/paths/internal_accounts/internal_accounts_{id}_balance-changes.yaml,…_statement-confirmations.yaml: new operationsopenapi/components/schemas/internal_accounts/:BalanceChange,BalanceChangeListResponse,ConfirmStatementDeliveryRequest,StatementDeliveryopenapi/components/schemas/errors/Error409.yaml:NOT_YET_AVAILABLEin both the description table and theenumopenapi/openapi.yaml: tag and path refs.stainless/stainless.yml:customers.list_balance_changes,customers.confirm_statement_delivery, and the four modelsopenapi.yaml,mintlify/openapi.yaml: regeneratedTest plan
make buildbundles cleanly, andopenapi.yamlandmintlify/openapi.yamlare identicalmake lintpasses: Redocly valid, Spectral 0 errors, and no new warnings or infos on any added path or schemaanyOfwithtype: 'null', following the repo's OpenAPI 3.1 convention🤖 Generated with Claude Code