Add end-user terms consent customer APIs

[ls-bolt]

This PR has been claimed. The active PR is now #798.

Summary

• add customer endpoints to fetch and update end-user terms consent
• expose the current Grid-hosted terms URL and version
• accept consent during customer creation and document the unregulated-platform requirement
• expose hasAcceptedEndUserTerms on customer responses so account-opening prerequisites are visible
• version identifiers are sequential (V1, then V2, V3, …) rather than release dates

Validation

• make lint

Requested by @bsiaotickchong

[vercel]

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

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ignored	Preview	Aug 4, 2026 8:40pm
grid-wallet-demo	Ignored	Preview	Aug 4, 2026 8:40pm

[lightspark-bot]

• Add end-user terms consent customer APIs #788 👈 (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

feat(api): add endUserTermsConsent parameter to customers create method

go

feat(api): add endUserTermsConsent parameter to business and individual customer create

kotlin

feat(api): add endUserTermsConsent field to customer create requests

openapi

feat(api): add end-user-terms consent endpoints and field to customers

php

feat(api): add endUserTermsConsent parameter to customer creation

python

feat(api): add end_user_terms_consent to customer create requests

ruby

feat(api): add end_user_terms_consent parameter to business/individual customer create

typescript

feat(api): add endUserTermsConsent parameter to customers create

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

⏳ grid-typescript studio · code · diff

generate ✅ → build ✅ → lint ⏳ → test ✅

npm install https://pkg.stainless.com/s/grid-typescript/2e44f91ea953085ad17d988328c612ecd2a05daa/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

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@b230d164c7edf226918ea9292d99ba4eade71ef0

⏳ grid-kotlin studio · code · diff

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

⏳ grid-php studio · code · diff

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 ❗

⏳ These are partial results; builds are still running.

---

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-08-04 20:51:05 UTC

[ls-bolt]

⚡ On it - adding the three new customer endpoints to the Stainless SDK configuration and validating the preview config. I’ll update here when it’s pushed.

---

🤖 fission-sentinel(#1) | Feedback

[ls-bolt]

Revision 2

• Added the three new consent/terms endpoints to the Stainless customers resource
• Registered the new request and response models so generated SDKs expose the methods
• Re-ran the repository lint successfully

---

🤖 fission-sentinel(#1) | Feedback

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
Grid	🟢 Ready	View Preview	Aug 1, 2026, 1:48 AM

[ls-bolt]

📌 Bolt Status

2026-08-03 17:26:40 UTC — ⚡ Agent fission-sentinel-4(#4) started
2026-08-04 04:46:15 UTC — ⚡ Agent fission-sentinel-7(#7) started

---

Feedback

[ls-bolt]

⚡ On it - evaluating whether consent status should be exposed on customer responses and checking the existing customer status model. I’ll update here with the resulting API change or rationale.

[ls-bolt]

Revision 3

• Added required hasAcceptedEndUserTerms to individual and business customer responses
• Marked the field read-only and documented how it relates to account opening
• Updated customer webhook examples for the expanded response schema
• Rebuilt the bundled specifications; make lint passes

[ls-bolt]

Revision update:

• added hasAcceptedEndUserTerms to customer responses
• documented END_USER_TERMS_VERSION_NOT_FOUND in Error400
• constrained consent ipAddress to 45 characters

@faraday please re-review the latest revision.

[shreyav]

do we need a whole new endpoint and resource for this, wondering if we can just put it on the customer

[ls-bolt]

I kept this customer-scoped resource intentionally. The common customer-read use case is covered by hasAcceptedEndUserTerms, so clients can see the account-opening prerequisite alongside the existing customer status without another request. The dedicated GET/PATCH is for the full acceptance evidence and its independent lifecycle: timestamp, terms version, method, and IP address. Embedding that object on every individual/business customer response and customer webhook would duplicate the schema and broaden exposure of audit/PII data, while we would still need a mutation surface to record re-acceptance. The original API requirement also explicitly calls for customer-ID-scoped get and update operations. My recommendation is therefore to keep the lightweight boolean on Customer and the full evidence behind /customers/{customerId}/end-user-terms-consent.

[ls-bolt]

⚡ On it — reconciling the dedicated consent endpoint with the customer-object alternative and the existing API requirements. I’ll follow up in the review thread.

[ls-bolt]

Review follow-up complete: I kept the customer-scoped consent GET/PATCH and explained the tradeoff in the inline thread. hasAcceptedEndUserTerms remains the lightweight status on customer responses; full acceptance evidence stays on the dedicated resource to avoid duplicating and broadly exposing audit data. No code change was needed, and CI is green.