Repository navigation
Split the Lead agreements by customer kind and drop the consent-count cap - #1053
Closed
ls-bolt[bot] wants to merge 1 commit into
Closed
ls-bolt[bot] wants to merge 1 commit into
ls-bolt[bot] wants to merge 1 commit into
Conversation
… cap A consumer and a commercial customer accept different Lead cardholder and accountholder documents, so each is its own agreement type rather than one type covering both. The array cap went with them. It restated a bound the type list already implies, and any new agreement silently invalidated it. The per-type uniqueness the description states is the real constraint.
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
github-actions
Bot
added
the
breaking-change
Contributor
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Contributor
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript Edit this comment to update them. They will appear in their respective SDK's changelogs. ✅ grid-typescript studio · code · diff
✅ grid-openapi studio · code · diff
✅ grid-kotlin studio · code · diff
✅ grid-ruby studio · code · diff
✅ grid-go studio · code · diff
✅ grid-python studio · code · diff
✅ grid-php studio · code · diff
✅ grid-cli studio · code · diff
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
bsiaotickchong
added a commit
that referenced
this pull request
Sep 23, 2026
… cap (#1061) ## Summary - Splits `LEAD_CARDHOLDER_AGREEMENT` and `LEAD_ACCOUNTHOLDER_AGREEMENT` into consumer and commercial variants. A consumer and a commercial customer accept different documents, so a single type cannot identify which one was accepted. - Removes the `maxItems: 7` cap on `agreementConsents` in the customer create and update requests. ## Why the cap goes It restated a bound the type list already implies, and it silently became wrong the moment a type was added — as this change demonstrates, since the list is now nine. A caller reading `maxItems: 7` learns nothing they could act on. The constraint that matters is already stated in the field description and enforced server-side: **at most one entry per type**. That one does not drift when the enum grows. ## Compatibility The two replaced values are not yet recorded against any customer, so no existing consent evidence refers to them. ``` LEAD_ACCOUNTHOLDER_AGREEMENT → LEAD_ACCOUNTHOLDER_CONSUMER_AGREEMENT LEAD_ACCOUNTHOLDER_COMMERCIAL_AGREEMENT LEAD_CARDHOLDER_AGREEMENT → LEAD_CARDHOLDER_CONSUMER_AGREEMENT LEAD_CARDHOLDER_COMMERCIAL_AGREEMENT ``` ## Test plan - `npm run build:openapi` regenerates both bundles; verified the new values are present and the replaced ones are gone from `openapi.yaml` and `mintlify/openapi.yaml`. - `npm run lint:openapi` exits 0. The only agreement-related output is a pre-existing informational note about a missing example on `AgreementConsentRequest.acceptedAt`, untouched by this change. Original PR: #1053 --------- Co-authored-by: bsiaotickchong <bsiaotickchong@users.noreply.github.com> Co-authored-by: Claude Opus 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
LEAD_CARDHOLDER_AGREEMENTandLEAD_ACCOUNTHOLDER_AGREEMENTinto consumer and commercial variants. A consumer and a commercial customer accept different documents, so a single type cannot identify which one was accepted.maxItems: 7cap onagreementConsentsin the customer create and update requests.Why the cap goes
It restated a bound the type list already implies, and it silently became wrong the moment a type was added — as this change demonstrates, since the list is now nine. A caller reading
maxItems: 7learns nothing they could act on.The constraint that matters is already stated in the field description and enforced server-side: at most one entry per type. That one does not drift when the enum grows.
Compatibility
The two replaced values are not yet recorded against any customer, so no existing consent evidence refers to them.
Test plan
npm run build:openapiregenerates both bundles; verified the new values are present and the replaced ones are gone fromopenapi.yamlandmintlify/openapi.yaml.npm run lint:openapiexits 0. The only agreement-related output is a pre-existing informational note about a missing example onAgreementConsentRequest.acceptedAt, untouched by this change.