Add ID_TYPE and ID_NUMBER to CustomerInfoFieldName

[mohamedwane]

Summary

• Adds ID_TYPE and ID_NUMBER to the CustomerInfoFieldName enum so platforms can pass sender identity documents in senderCustomerInfo on quote create.
• Required for Thunes corridors where the upstream payer spec demands sender identity on every payer combination — currently EGP. The receiver-side field provider in sparkcore (PR #27983) already advertises these fields as required at LNURLP time; this PR closes the last gap so the request validator accepts them.

Test plan

• Verify the bundled openapi.yaml re-generated cleanly with only the two added enum values (no unrelated drift)
• After merge, run update_schema.sh in webdev/grid-api/ to regenerate Pydantic models; verify the regenerated customer_info_field_name.py includes ID_TYPE = 'ID_TYPE' and ID_NUMBER = 'ID_NUMBER'
• Retry the failing EGP quote-create against the Housing & Development Bank external account; expect quote success (or a different downstream error that's no longer about field-name validation)

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ignored		Jun 3, 2026 8:15pm

[github-actions]

✱ Stainless preview builds for grid

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

cli

chore(internal): regenerate SDK with no functional changes

csharp

feat(api): add IDType/IDNumber to CustomerInfoFieldName enum

go

feat(api): add ID_TYPE and ID_NUMBER to CustomerInfoFieldName

kotlin

feat(api): add ID_TYPE and ID_NUMBER to CustomerInfoFieldName

openapi

feat(api): add ID_TYPE and ID_NUMBER to CounterpartyFieldType enum

php

feat(types): add ID_TYPE and ID_NUMBER to CustomerInfoFieldName enum

python

feat(api): add ID_TYPE and ID_NUMBER to CustomerInfoFieldName

ruby

feat(api): add ID_TYPE and ID_NUMBER values to CustomerInfoFieldName enum

typescript

feat(api): add ID_TYPE and ID_NUMBER to CustomerInfoFieldName enum

✅ grid-openapi studio · code

Your SDK build had at least one "note" diagnostic.
generate ✅

✅ grid-ruby studio · code

Your SDK build had at least one "note" diagnostic.
generate ✅ → build ✅ → lint ✅ → test ✅

⚠️ grid-kotlin studio · code

Your SDK build had a failure in the test CI job, which is a regression from the base state.
generate ✅ → build ✅ → lint ✅ → test ❗

✅ grid-typescript studio · code

Your SDK build had at least one "note" diagnostic.
generate ✅ → build ✅ → lint ✅ → test ✅

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

⚠️ grid-python studio · code

Your SDK build had a failure in the lint CI job, which is a regression from the base state.
generate ✅ → build ✅ → lint ❗ → test ❗

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

⚠️ grid-csharp studio · code

Your SDK build had a failure in the build CI job, which is a regression from the base state.
generate ⚠️ → build ❗ → lint ✅ → test ❗

⚠️ grid-go studio · code

Your SDK build had a failure in the lint CI job, which is a regression from the base state.
generate ✅ → build ✅ → lint ❗ → test ❗

go get github.com/stainless-sdks/grid-go@57a7bead833a076daa87d59ac07cfd4b75d45888

✅ grid-php studio · code

Your SDK build had at least one "note" diagnostic.
generate ✅ → lint ✅ → test ✅

⚠️ grid-cli studio · code

Your SDK build had a failure in the test CI job, which is a regression from the base state.
generate ⚠️ → build ⏭️ → lint ⏭️ → test ❗

---

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-06-03 21:09:00 UTC

[greptile-apps]

Greptile Summary

Adds ID_TYPE and ID_NUMBER to the CustomerInfoFieldName enum to support sender identity document fields required by Thunes/EGP corridors. The edit is made in the correct source directory (openapi/components/schemas/customers/) and the two generated bundles (openapi.yaml and mintlify/openapi.yaml) reflect the same delta, consistent with a make build pass.

• openapi/components/schemas/customers/CustomerInfoFieldName.yaml — source-of-truth edit; the two new values follow the same ALL_CAPS naming convention as existing entries.
• openapi.yaml and mintlify/openapi.yaml — regenerated bundles updated consistently with no unrelated drift.

Confidence Score: 5/5

Safe to merge — adds two enum values to a string schema with no breaking changes to existing consumers.

The change is purely additive: two new enum values in an OpenAPI string schema. The source file was edited in the correct location, both generated bundles are consistent with one another, naming follows the existing convention, and there is no drift in the regenerated files beyond the intended delta.

No files require special attention.

Important Files Changed

Filename	Overview
openapi/components/schemas/customers/CustomerInfoFieldName.yaml	Source schema file — adds ID_TYPE and ID_NUMBER to the enum; correct place to make the edit per CLAUDE.md conventions.
openapi.yaml	Generated bundle — mirrors the source change with the same two enum values, consistent with a make build regeneration.
mintlify/openapi.yaml	Mintlify-targeted generated bundle — identical delta to openapi.yaml, consistent with a single build pass.

Sequence Diagram

sequenceDiagram
    participant Platform
    participant GridAPI as Grid API (quote create)
    participant Validator as Field Validator
    participant Sparkcore

    Platform->>GridAPI: "POST /quotes { senderCustomerInfo: { ID_TYPE, ID_NUMBER } }"
    GridAPI->>Validator: Validate CustomerInfoFieldName enum
    Note over Validator: Now accepts ID_TYPE and ID_NUMBER
    Validator-->>GridAPI: Valid
    GridAPI->>Sparkcore: Forward quote request
    Sparkcore-->>GridAPI: Quote response
    GridAPI-->>Platform: Quote created

Loading

_{Reviews (1): Last reviewed commit: "Add ID_TYPE and ID_NUMBER to CustomerInf..." | Re-trigger Greptile}