Split request and response schemas for external account paymentRails

[AaryamanBhute]

Summary

• Split the external account create request and response schemas so that paymentRails is only present in the response, not the request
• Each common *AccountInfo.yaml is now split into *AccountInfoBase.yaml (without paymentRails) and *AccountInfo.yaml (allOf composition with paymentRails)
• New *ExternalAccountCreateInfo.yaml schemas reference the Base variants (no paymentRails), while response schemas continue using the full *AccountInfo.yaml
• Request examples in endpoint files updated to remove paymentRails

Test plan

• make build passes - OpenAPI spec bundles successfully
• make lint-openapi passes - validation reports Your API description is valid
• Verify generated docs render correctly with make mint

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ready	Preview, Comment	Mar 27, 2026 4:54am

[github-actions]

✱ Stainless preview builds

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

kotlin

feat: Split request and response schemas for external account paymentRails

openapi

feat: Split request and response schemas for external account paymentRails

python

feat: Split request and response schemas for external account paymentRails

typescript

feat: Split request and response schemas for external account paymentRails

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

✅ grid-typescript studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ✅ → build ✅ → lint ✅ (prev: lint ❗) → test ✅

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

New diagnostics (40 note)

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

✅ grid-python studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ✅ → build ✅ → lint ✅ (prev: lint ❗) → test ✅

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

New diagnostics (40 note)

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

✅ grid-openapi studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ✅

New diagnostics (42 note)

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

✅ grid-kotlin studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ✅ → build ✅ → lint ✅ → test ✅

New diagnostics (196 note)

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

---

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-27 04:59:59 UTC

[AaryamanBhute]

[Hurlicane-Aary] ## PR Review: Split request/response schemas for external account paymentRails

Overall: Looks good. The approach is clean and the pattern is applied consistently across all 27 currency account types.

What this does

1. Splits each *AccountInfo.yaml into *AccountInfoBase.yaml (core fields without paymentRails) and *AccountInfo.yaml (allOf composition adding paymentRails as required)
2. Creates new *ExternalAccountCreateInfo.yaml schemas for each currency that reference the Base variant (no paymentRails)
3. Introduces ExternalAccountCreateInfoOneOf.yaml as the discriminated union for create requests
4. Updates ExternalAccountCreateRequest and PlatformExternalAccountCreateRequest to use the new create-specific oneOf
5. Response schemas (ExternalAccountInfoOneOf) remain unchanged — responses still include paymentRails
6. Request examples in endpoint files correctly remove paymentRails

Correctness ✅

• The allOf composition in each *AccountInfo.yaml correctly extends the Base with a required paymentRails field — response schemas are preserved.
• The ExternalAccountCreateInfoOneOf discriminator mapping is complete and consistent with the existing ExternalAccountInfoOneOf.
• ExternalAccountDetailsDestination.yaml (used in quotes) correctly references ExternalAccountCreateRequest, which now uses the create-specific schemas — this is the right call since it's a create context.
• The BaseExternalAccountInfo shared schema is reused properly in all new *ExternalAccountCreateInfo.yaml files.

Design ✅

• The *Base / *Full pattern via allOf is the standard OpenAPI approach for this kind of request/response divergence. Clean choice.
• The naming convention (*AccountInfoBase for shared fields, *AccountInfo for response-complete, *ExternalAccountCreateInfo for request) is clear and consistent.

No blockers found.

One minor note (non-blocking): The PR branch includes 8 commits from other already-merged PRs (#295, #296, #297, #300, etc.). Consider rebasing onto main before merge to keep the history clean, though this is cosmetic.

[AaryamanBhute]

[Hurlicane-Aary] @greptile review

[greptile-apps]

Greptile Summary

This PR cleanly splits the external account paymentRails field out of create-request schemas while keeping it present in response schemas. Each existing *AccountInfo.yaml (27 fiat currencies) is refactored into a *AccountInfoBase.yaml (all fields except paymentRails) plus a composed *AccountInfo.yaml (allOf Base + paymentRails). New *ExternalAccountCreateInfo.yaml schemas wrap the base variants for use in request bodies. Response schemas (*ExternalAccountInfo.yaml and ExternalAccountInfoOneOf.yaml) are untouched and continue to resolve paymentRails through the updated allOf composition.

Key changes:

• 27 new *AccountInfoBase.yaml schemas in openapi/components/schemas/common/ — one per fiat currency
• 27 refactored *AccountInfo.yaml files now use allOf to compose Base + paymentRails
• 27 new *ExternalAccountCreateInfo.yaml schemas in openapi/components/schemas/external_accounts/
• New ExternalAccountCreateInfoOneOf.yaml discriminator union used by both create-request types
• paymentRails removed from USD request body examples in both customer and platform endpoint files
• Bundled openapi.yaml and mintlify/openapi.yaml regenerated; make build and make lint-openapi both pass

Confidence Score: 5/5

Safe to merge — all 27 fiat currencies are covered correctly, build and lint pass, and no logical issues were found in the schema split

The refactoring is mechanically consistent across all 27 fiat currencies: Base schemas correctly extract every field except paymentRails, composed AccountInfo schemas correctly re-add paymentRails via allOf, new CreateInfo schemas correctly reference the Base variants, and the existing response schemas remain untouched. The discriminator union entries match between request and response oneOfs. Both make build and make lint-openapi pass per the test plan.

No files require special attention

Important Files Changed

Filename	Overview
openapi/components/schemas/external_accounts/ExternalAccountCreateInfoOneOf.yaml	New request-side discriminator union — all 27 fiat currencies point to *CreateInfo variants (no paymentRails), crypto wallets reuse existing schemas unchanged; mapping is complete and consistent
openapi/components/schemas/external_accounts/ExternalAccountCreateRequest.yaml	Single-line change swapping accountInfo $ref from ExternalAccountInfoOneOf to ExternalAccountCreateInfoOneOf — correct
openapi/components/schemas/external_accounts/PlatformExternalAccountCreateRequest.yaml	Mirrors ExternalAccountCreateRequest.yaml — accountInfo now points to ExternalAccountCreateInfoOneOf; correct
openapi/components/schemas/common/UsdAccountInfo.yaml	Refactored to allOf composition (UsdAccountInfoBase + paymentRails); response schemas continue to resolve all required fields
openapi/components/schemas/common/UsdAccountInfoBase.yaml	New base schema with all USD account fields except paymentRails; used by UsdExternalAccountCreateInfo for request bodies
openapi/components/schemas/external_accounts/UsdExternalAccountCreateInfo.yaml	New create schema: allOf [BaseExternalAccountInfo + UsdAccountInfoBase + beneficiary]; no paymentRails — correctly mirrors UsdExternalAccountInfo but without that field
openapi/paths/customers/customers_external_accounts.yaml	paymentRails removed from POST request body example — consistent with schema change
openapi/paths/platform/platform_external_accounts.yaml	paymentRails removed from POST request body example — consistent with schema change

Class Diagram

%%{init: {'theme': 'neutral'}}%%
classDiagram
    class UsdAccountInfoBase {
        +accountType: USD_ACCOUNT
        +accountNumber: string
        +routingNumber: string
    }
    class UsdAccountInfo {
        +paymentRails: array
    }
    class UsdExternalAccountCreateInfo {
        +beneficiary: object
    }
    class UsdExternalAccountInfo {
        +beneficiary: object
    }
    class ExternalAccountCreateRequest {
        +accountInfo: ExternalAccountCreateInfoOneOf
    }
    class ExternalAccountCreateInfoOneOf {
        discriminator: accountType
    }
    class ExternalAccountInfoOneOf {
        discriminator: accountType
    }

    UsdAccountInfo --|> UsdAccountInfoBase : allOf
    UsdExternalAccountCreateInfo --|> UsdAccountInfoBase : allOf (no paymentRails)
    UsdExternalAccountInfo --|> UsdAccountInfo : allOf (with paymentRails)
    ExternalAccountCreateRequest --> ExternalAccountCreateInfoOneOf : accountInfo
    ExternalAccountCreateInfoOneOf --> UsdExternalAccountCreateInfo : USD_ACCOUNT
    ExternalAccountInfoOneOf --> UsdExternalAccountInfo : USD_ACCOUNT

Loading

_{Reviews (2): Last reviewed commit: "[Hurlicane-Aary] split external account ..." | Re-trigger Greptile}