add status to internal account

[wuvictor-95]

No description provided.

[wuvictor-95]

• add status to internal account #244 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

✱ Stainless preview builds

This PR will update the grid SDKs with the following commit messages.

kotlin

feat(api): add status field to InternalAccount

openapi

feat(api): add status field and InternalAccountStatus enum to InternalAccount

python

feat(api): add status field to sandbox internal_account

typescript

feat(api): add status field to InternalAccount

Edit this comment to update them. They will appear in their respective SDK's changelogs.

✅ grid-openapi studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅

✅ grid-python studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ✅ → lint ✅ → test ✅

pip install https://pkg.stainless.com/s/grid-python/7752d0250cd90d4e503fede22509de5ed2f3b6b3/grid-0.0.1-py3-none-any.whl

✅ grid-kotlin studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ❗ → lint ✅ → test ❗

✅ grid-typescript studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅ → build ✅ → lint ✅ → test ✅

npm install https://pkg.stainless.com/s/grid-typescript/acecacfc872368a4c273184062c81544b724f5fb/dist.tar.gz

---

This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-03-04 03:25:55 UTC

[greptile-apps]

Greptile Summary

This PR adds a status field to the InternalAccount schema, backed by a new InternalAccountStatus enum (PENDING, OPEN, CLOSED, FROZEN). The change is applied consistently across the source schema (openapi/components/schemas/customers/), the compiled openapi.yaml, and the Mintlify public-facing spec.

Key changes:

• New InternalAccountStatus.yaml enum schema with four values: PENDING, OPEN, CLOSED, FROZEN
• status added to InternalAccount as a required response field
• Both openapi.yaml and mintlify/openapi.yaml are updated in sync with the source

Concern:

• status is introduced directly as required, which assumes all existing InternalAccount records already have a status value and the backend always returns it. If any records were created before the backend migration populates this field, the server would violate its own contract. The safer pattern is to ship it as optional first, backfill existing records, then promote it to required.

Confidence Score: 4/5

• Safe to merge if the backend is already deployed and returns status for all existing InternalAccount records.
• The schema changes are minimal and well-formed. The only concern is marking status as required immediately rather than optional, which could be problematic if any existing records lack a status or the backend deployment hasn't landed yet.
• openapi/components/schemas/customers/InternalAccount.yaml — verify the backend is already returning status for all existing records before merging with required.

Important Files Changed

Filename	Overview
openapi/components/schemas/customers/InternalAccountStatus.yaml	New file defining the InternalAccountStatus enum with four values: PENDING, OPEN, CLOSED, FROZEN. Schema is well-formed.
openapi/components/schemas/customers/InternalAccount.yaml	Adds status as a required field to InternalAccount. Marking it required immediately (rather than optional first) is a potentially non-backward-compatible change if existing records lack a status or the backend hasn't been fully deployed yet.
openapi.yaml	Compiled OpenAPI spec updated with InternalAccountStatus enum and status field on InternalAccount; mirrors the source schema changes correctly.
mintlify/openapi.yaml	Mintlify public-facing spec updated identically to openapi.yaml; changes are in sync.

Entity Relationship Diagram

%%{init: {'theme': 'neutral'}}%%
erDiagram
    InternalAccount {
        string id
        InternalAccountStatus status
        string customerId
        CurrencyAmount balance
        array fundingPaymentInstructions
        datetime createdAt
        datetime updatedAt
    }

    InternalAccountStatus {
        enum PENDING
        enum OPEN
        enum CLOSED
        enum FROZEN
    }

    InternalAccount ||--|| InternalAccountStatus : "has"

Loading

_{Last reviewed commit: 371a1ec}

[greptile-apps]

Required field on existing response schema

status is being introduced directly as a required field on the InternalAccount response object. This is a potentially breaking change for existing API consumers: any auto-generated client SDKs built from the old schema will now have a non-optional status field, and any client doing strict schema validation against the old spec will fail when they receive the new field.

More critically, if there are already existing InternalAccount records in the database that were created before a corresponding backend migration populates status, the server would either have to synthesize a default value or return a response that violates its own contract.

The safer approach is to introduce the field as optional first (omit it from required), deploy the schema + backend together once all existing records are backfilled, and then promote it to required in a follow-up PR:

Suggested change

	type: object
	required:
	- id
	- balance
	- fundingPaymentInstructions
	- createdAt
	- updatedAt
	properties:
	id:
	type: string
	description: The ID of the internal account
	example: InternalAccount:12dcbd6-dced-4ec4-b756-3c3a9ea3d123
	status:
	$ref: ./InternalAccountStatus.yaml

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/customers/InternalAccount.yaml
Line: 1-16

Comment:
**Required field on existing response schema**

`status` is being introduced directly as a `required` field on the `InternalAccount` response object. This is a potentially breaking change for existing API consumers: any auto-generated client SDKs built from the old schema will now have a non-optional `status` field, and any client doing strict schema validation against the old spec will fail when they receive the new field.

More critically, if there are already existing `InternalAccount` records in the database that were created before a corresponding backend migration populates `status`, the server would either have to synthesize a default value or return a response that violates its own contract.

The safer approach is to introduce the field as optional first (omit it from `required`), deploy the schema + backend together once all existing records are backfilled, and then promote it to `required` in a follow-up PR:

```suggestion
type: object
required:
  - id
  - balance
  - fundingPaymentInstructions
  - createdAt
  - updatedAt
properties:
  id:
    type: string
    description: The ID of the internal account
    example: InternalAccount:12dcbd6-dced-4ec4-b756-3c3a9ea3d123
  status:
    $ref: ./InternalAccountStatus.yaml
```

How can I resolve this? If you propose a fix, please make it concise.