feat: add REGISTRATION_ADDRESS to CustomerInfoFieldName

[peterrojs]

Summary

Adds REGISTRATION_ADDRESS to the CustomerInfoFieldName enum.

REGISTRATION_ADDRESS already exists as a requestable counterparty data field, but there was no matching CustomerInfoFieldName value — so a business sender's registration address, when requested and on file, could not be represented as sender customer info. Adding the value lets it be carried through the quote/sender-info path like other counterparty fields (e.g. POSTAL_ADDRESS).

Changes

• openapi/components/schemas/customers/CustomerInfoFieldName.yaml — add REGISTRATION_ADDRESS
• Rebundled: openapi.yaml, mintlify/openapi.yaml (via make build)

Additive, backward-compatible enum addition. make lint-openapi passes (no new findings).

Requested by @JasonCWang

Original PR: #694

[akanter]

• feat: add REGISTRATION_ADDRESS to CustomerInfoFieldName #695 👈 (View in Graphite)
• main

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

[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

go

feat(api): add REGISTRATION_ADDRESS to CustomerInfoFieldName enum

kotlin

feat(api): add registration_address to CustomerInfoFieldName enum

openapi

feat(api): add REGISTRATION_ADDRESS enum value

php

feat(api): add REGISTRATION_ADDRESS to customer info fields

python

feat(api): add REGISTRATION_ADDRESS to CustomerInfoFieldName enum

ruby

feat(api): add REGISTRATION_ADDRESS to CustomerInfoFieldName enum

typescript

feat(api): add REGISTRATION_ADDRESS to CustomerInfoFieldName enum

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 "note" diagnostic, but this did not represent a regression.
generate ✅ → build ✅ → lint ❗ → test ✅

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

✅ grid-openapi studio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
generate ⚠️

✅ grid-ruby studio · code · diff

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

✅ grid-go studio · code · diff

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

go get github.com/stainless-sdks/grid-go@2fb270dc180ba7a1361bac7c503299fc503ed300

✅ grid-kotlin studio · code · diff

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

✅ 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/d8cf0a1dc4d4bb2ad5b7acc8be0cdb1500268dba/grid-0.0.1-py3-none-any.whl

✅ grid-php studio · code · diff

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

✅ grid-cli studio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
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-07-16 16:34:53 UTC

[greptile-apps]

Greptile Summary

This PR adds REGISTRATION_ADDRESS to the CustomerInfoFieldName enum, enabling a business sender's registration address to be carried through the quote/sender-info path alongside existing fields like POSTAL_ADDRESS. The change is purely additive and backward-compatible.

• openapi/components/schemas/customers/CustomerInfoFieldName.yaml — source-of-truth enum updated with REGISTRATION_ADDRESS inserted between POSTAL_ADDRESS and TAX_ID.
• openapi.yaml and mintlify/openapi.yaml — both bundled specs updated in sync via make build, reflecting the identical change at the same line.

Confidence Score: 5/5

This is a purely additive enum value addition with no logic changes — safe to merge.

The change adds a single enum value to a schema definition and correctly regenerates both bundled OpenAPI specs. All three files are in sync, the placement is consistent with surrounding values, and no existing behavior is altered.

No files require special attention.

Important Files Changed

Filename	Overview
openapi/components/schemas/customers/CustomerInfoFieldName.yaml	Source enum definition: adds REGISTRATION_ADDRESS between POSTAL_ADDRESS and TAX_ID — clean, consistent, no other changes.
openapi.yaml	Bundled spec: REGISTRATION_ADDRESS added at the same position as the source file; diff matches mintlify/openapi.yaml exactly.
mintlify/openapi.yaml	Mintlify bundled spec: identical update to openapi.yaml, correctly regenerated via make build.

Class Diagram

%%{init: {'theme': 'neutral'}}%%
classDiagram
    class CustomerInfoFieldName {
        <<enumeration>>
        FULL_NAME
        BIRTH_DATE
        NATIONALITY
        PHONE_NUMBER
        EMAIL
        POSTAL_ADDRESS
        REGISTRATION_ADDRESS
        TAX_ID
        REGISTRATION_NUMBER
        USER_TYPE
        COUNTRY_OF_RESIDENCE
        ACCOUNT_IDENTIFIER
        ...
    }

    class CounterpartyFieldDefinition {
        +name: CustomerInfoFieldName
        +mandatory: boolean
    }

    CounterpartyFieldDefinition --> CustomerInfoFieldName : uses

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
classDiagram
    class CustomerInfoFieldName {
        <<enumeration>>
        FULL_NAME
        BIRTH_DATE
        NATIONALITY
        PHONE_NUMBER
        EMAIL
        POSTAL_ADDRESS
        REGISTRATION_ADDRESS
        TAX_ID
        REGISTRATION_NUMBER
        USER_TYPE
        COUNTRY_OF_RESIDENCE
        ACCOUNT_IDENTIFIER
        ...
    }

    class CounterpartyFieldDefinition {
        +name: CustomerInfoFieldName
        +mandatory: boolean
    }

    CounterpartyFieldDefinition --> CustomerInfoFieldName : uses

Loading

_{Reviews (1): Last reviewed commit: "feat: add REGISTRATION_ADDRESS to Custom..." | Re-trigger Greptile}

[ls-bolt]

Closing — after confirming REGISTRATION_ADDRESS isn't consumed anywhere in the payment flow, we're dropping the field at the source rather than adding it to the enum. No spec change needed. Thanks @peterrojs!